resolve: Minimize hacks in name resolution of primitive types

[petrochenkov]

When resolving the first unqualified segment in a path with n segments and n - 1 associated item segments, e.g. (a or a::assoc or a::assoc::assoc etc) try to resolve a without considering primitive types first. If the "normal" lookup fails or results in a module, then try to resolve a as a primitive type as a fallback.

This way backward compatibility is respected, but the restriction from E0317 can be lifted, i.e. primitive names mostly can be shadowed like any other names.

Furthermore, if names of primitive types are put into prelude (now it's possible to do), then most of names will be resolved in conventional way and amount of code relying on this fallback will be greatly reduced. Although, it's not entirely convenient to put them into prelude right now due to temporary conflicts like use prelude::v1::*; use usize; in libcore/libstd, I'd better wait for proper glob shadowing before doing it.
I wish the no_prelude attribute were unstable as intended :(

cc @jseyfried @arielb1
r? @eddyb

[eddyb]

LGTM, but I'd like to see a decision from @rust-lang/lang.

[jseyfried]

Looks good to me, +1 for this change.

I'm having trouble seeing why this isn't backwards compatible -- @petrochenkov can you come up with an example that breaks?

[jseyfried]

I believe this resolves to ::std::u8::MAX; MAX is not an associated const of <u8>.

[petrochenkov]

I'll fix the example

[petrochenkov]

I'm having trouble seeing why this isn't backwards compatible

For some reason I thought extern crates have their own Def, but it turns out they are Def::Mod too and E0317 prevented any other breakage. So, yes, it looks like this change is completely backward compatible.

(The changes to prelude will require a crater run though, but I've not included them in this PR)

[jseyfried]

this change is completely backward compatible

Excellent. I can't think of any other reason to continue disallowing types that would shadow primitive types.

The changes to prelude will require a crater run though, but I've not included them in this PR

The prelude is shadowable by everything else, so I think it would be backwards compatible to add to the prelude for all code that doesn't manually import the prelude.

[jseyfried]

@petrochenkov What would you think about moving to disallow modules that shadow primitive types?

Then, once associated consts stabilize, we could make MAX and MIN associated constants of the type u8 (for example), make std::u8 the type instead of the module, and then stop special-casing primitive types relative to the rest of the prelude.

Without modules that shadow primitive types, I believe this change would be backwards compatible (except for use std::u8::MAX, unless we made associated consts importable).

[petrochenkov]

backwards compatible ... for all code that doesn't manually import the prelude

#![no_implicit_prelude] not being feature gated is exactly the reason why it may be a breaking change for code on stable.

we could make MAX and MIN associated constants of the type u8 (for example), make std::u8 the type instead of the module, and then stop special-casing primitive types.

"Numeric" modules are more or less fixable if associated constants are improved, but we also have http://doc.rust-lang.org/nightly/std/str/...

[jseyfried]

Ok, but #![no_implicit_prelude] is rarely used in stable Rust and on its way to deprecation.

str certainly doesn't look fixable before 2.0. I still think it might be a good idea to disallow modules that shadow the numeric primitive types.

[aturon]

Nominated for discussion at next lang team meeting.

[nikomatsakis]

On Wed, Mar 09, 2016 at 12:51:41AM -0800, Jeffrey Seyfried wrote:

Then, once associated consts stabilize, we could make MAX and MIN associated constants of the type u8 (for example) and make std::u8 the type instead of the module. Without modules that shadow primitive types, I believe this change would be backwards compatible (except for use std::u8::MAX, unless we made associated consts importable).

I do hope we will do this eventually; I think making imports of associated items work would be a pre-req to doing such a change.

[nikomatsakis]

Is another way to view "no implicit prelude" as actually giving you a smaller prelude, that just contains the builtin numeric types?

Also, I think we could get away with retroactively feature-gating no-implicit-prelude, which seems like something we did not mean to stabilize.

[petrochenkov]

@jseyfried

What would you think about moving to disallow modules that shadow primitive types?

Sorry, I haven't answered to this.
What is the purpose of this restriction? Reducing reliance of people on the fallback?
An experiment with crater wouldn't hurt, but I doubt this is a viable idea due to compatibility, I've definitely seen such modules used somewhere outside of the standard library.
I have a more targeted solution - a new unstable attribute #[this_module_permits_fallback_to_primitive_types]. This attribute could be applied (temporarily if possible) to several modules in the standard library (std::u8/std::str/etc), all other modules will shadow primitive types properly. It has the fewer compatibility problems and the same prerequisites:

1. Primitive types should be available in qualified form, i.e. std::primitive::u8. This way they can be used when shadowed by a module (or anything else) + they can be used in use directives as a bonus.

mod S {}
type A = S;

should give an error message "S is a module and not a type" and not "type name S is undefined or not in scope" like now.

[petrochenkov]

Also, I think we could get away with retroactively feature-gating no-implicit-prelude, which seems like something we did not mean to stabilize.

+1

Is another way to view "no implicit prelude" as actually giving you a smaller prelude, that just contains the builtin numeric types?

With prelude changes from #32167 the fallback implemented in this PR starts looking like kind of a small lower priority prelude hardcoded in the resolve (except for "legacy" module shadowing) :)
Edit: It can be "un-hardcoded", but I don't see strong reasons to do this so far.

[jseyfried]

@nikomatsakis yeah, I think that is a good way to view #[no_implicit_prelude].

@petrochenkov

I have a more targeted solution - a new unstable attribute #[...fallback_to_primitive_types]

I really like this idea! I think we could take this further by including the primitive type modules in the prelude, only allowing primitive types to be used via a #[primitive_type] module, and cleaning up the fallback semantics. Then,

• We could think of the #[primitive_type] modules as special type/module hybrids, most of which could be backwards-compatibly replaced with ordinary types once associated consts are stabilized and importable. In particular,
  • A #[primitive_type] module used as the last segment (or sole segment) in a path would resolve to the type (except when being imported).
  • Otherwise, it would resolve to the type unless the following segment resolved in the module.
• We wouldn't need to make the primitive types specially available; std::u8, etc. would work.
• #[no_implicit_prelude] would really mean no prelude, not just a smaller prelude.
• Users could recover #[no_implicit_prelude]'s current behavior by importing just the primitive type modules or creating a custom prelude with just these modules.

[jseyfried]

Finally, we could avoid any immediate breakage with a warning cycle, something like:

mod u8 {}
fn f(_: u8) {}
//~^ WARN the type `u8` is shadowed by the user-defined module `::u8`, use `::std::u8` instead

[petrochenkov]

#[no_implicit_prelude] would really mean no prelude, not just a smaller prelude.

I'm not sure removing primitive types together with the main prelude is practical. I need to experiment with libcore as the main consumer of no prelude.

We could think of the #[primitive_type] modules as special type/module hybrids, ...

I suspect this will turn out to be much larger hack, then the current fallback.
Edit: Or maybe not! Now I think I've got the idea, I'll try to implement it this evening. (We still need to make sure that development of libcore doesn't turn into hell without primitive types available by default.)

[jseyfried]

I suspect this will turn out to be much larger hack, then the current fallback.

I think of it as less of a hack if the semantics are cleaner (which I believe they would be).

Also, the current implementation can be so simple only because resolve_possibly_assoc_item is a hack -- once we rewrite that, I think my semantics would be no more complicated to implement.

[petrochenkov]

@jseyfried
This is how libcore looks with primitive types disabled by default: https://github.com/petrochenkov/rust/tree/noprimcore
I haven't finished the work completely, but basically you have to manually import primitive types into almost every module, you can't do much without them. It's very inconvenient.
I think the solution is simple - make prelude injection crate-level (#32167 (comment)) and manually inject libcore's own prelude into its root once (I hope this won't break import resolution?).
After that #[primitive_type] can be implemented and primitive types can be put into the main prelude, because uses of no_prelude outside of libcore are exceedingly rare according to the crates.io grep.

[jseyfried]

make prelude injection crate-level and manually inject libcore's own prelude into its root once

Completely agree.

In the mean time, perhaps we could leverage the existing prelude injection by adding a private module std in libcore:

mod std {
    pub use prelude; // i.e. `libcore`'s prelude
}

and enabling ordinary prelude injection in libcore.

[bors]

☔ The latest upstream changes (presumably #32182) made this pull request unmergeable. Please resolve the merge conflicts.

[petrochenkov]

I've implemented #[primitive_type] (mostly, std::u8 still doesn't resolve to the type u8 in type positions, but it doesn't matter much) and I don't know if I like the result or not
https://github.com/petrochenkov/rust/tree/prim3
Please share your opinion.

Primitive types are bound to items in libcore (and also libcollections, librustc_unicode, libstd, all necessary for compatibility), mostly to modules, but bool doesn't have compatibility issues and can be bound to anything - enum bool {} or even type bool = bool;.
Most of the time were spent on fixing libcore, libstd and all those no_core and no_implivit_prelude tests.

cc @eddyb, you wanted to do this looong time ago

[jseyfried]

Nice! I definitely like the result.

[eddyb]

How about enum bool { false = 0, true = 1 }?

[petrochenkov]

@eddyb

How about enum bool { false = 0, true = 1 }?

For documentation purpose only (the item body is ignored) or rust-lang/rfcs#348?
(Either way requires demoting true and false from keywords.)

@jseyfried

Nice! I definitely like the result.

Ok, I'll fix the std::u8 bug, submit prim3 as a separate PR and let the lang team decide.

[bors]

⌛ Testing commit b418cd2 with merge ab13e5a...

[bors]

⛄ The build was interrupted to prioritize another pull request.

[bors]

⌛ Testing commit b418cd2 with merge 1ab7b62...

[bors]

⛄ The build was interrupted to prioritize another pull request.

[bors]

⌛ Testing commit b418cd2 with merge 5b39678...

[bors]

⛄ The build was interrupted to prioritize another pull request.

[bors]

⌛ Testing commit b418cd2 with merge c10b1e9...

[bors]

⛄ The build was interrupted to prioritize another pull request.