Redefining built-in types does not work

[Marckvdv]

The following code does not do what I expect it to do:

type int = i8;
println!("{}", std::mem::size_of::<int>()); // => prints 8, should be 1? Or shouldn't it compile at all?

[brson]

Nominating. Seems like this should be well-defined, though this behavior may be so useless there's no backwards compat risk.

[brson]

Could possibly do post-1.0 bugfix.

[petrochenkov]

@brson
I'm trying to fix this.
It takes place because in resolve_type for paths built-in names are searched first and the user-defined names are searched last. If I switch the order, then a lot of code breaks, because in cases like

use std::usize;
fn f() -> usize {}

the name lookup rightfully resolves usize as the module std::usize, because types and modules share the namespace.
I'm continuing to study rustc_resolve for now to come up with a better solution, but would be glad to recieve any advice.

[petrochenkov]

So, the current algorithm is:

• if built-in name is a full path (u8) then it is resolved as built-in type
• if built-in name is a part of full path (segment1::u8::segment2) then it is processed as all other user-defined names

Modules, unlike most of other items, are not exposed to the discussed problem just because they are never full paths.

It is possible to prohibit the built-in names only for items that can be used as full paths and are searched in type namespace, but IMO the most drastic solution would be the most appropriate here - prohibit built-in names for everything except for modules. Reusing the names of built-in types is never a good idea and modules are just an unfortunate exception.

[petrochenkov]

/cc @aturon

[aturon]

@petrochenkov

prohibit built-in names for everything except for modules

To be clear: you're saying that you would not be able to define types (or values?) with names matching any primitive type? But modules are OK?

That sounds potentially fine to me (and can always be relaxed later).

cc @nikomatsakis

[petrochenkov]

To be clear: you're saying that you would not be able to define types (or values?) with names matching any primitive type? But modules are OK?

Yes, only module items will be able to have names matching built-in types.

[petrochenkov]

A more fine-grained prohibition turned out to be easier to implement.
See PR #22093