Stabilize uniform paths on Rust 2018 (technical details)

[petrochenkov]

#55618 is the high-level and high-volume thread on whether we want uniform import paths in the language in general or not.
This is a more focused issue about how exactly stabilization will happen (assuming it will happen in general).

First, regarding timing of the stabilization.
I propose to test uniform paths for 4-5 weeks starting from Dec 07 (Rust 2018 release, 1.31 stable), and then backport their stabilization on 1.32 beta if everything is good.

Second, regarding sub-features and partial stabilization.
Imports use NAME or use NAME::... in the uniform path model can refer to various entities, not all of which may be expected or were discussed.
Here's the list:

• Items defined in named or unnamed modules (mod m { struct NAME; }, fn f() { struct NAME; }).
  No known issues to resolve before stabilization.
• Macros from other crates imported with #[macro_use] extern crate ..., for example use panic from the standard library.
  No known issues to resolve before stabilization.
• Extern crate names from extern prelude, for example use std or use regex.
  No known issues to resolve before stabilization.
• Names from the standard library prelude, for example use Vec.
  No known issues to resolve before stabilization.
• Built-in types, for example use u8.
  No known issues to resolve before stabilization.
• Built-in macros, for example use env.
  Currently an error due to some (fixable) implementation details of built-in macros.
  No known issues to resolve before stabilization (after the error is removed).
• Macros defined with macro_rules! in the same crate, e.g. macro_rules! mac {()=>()} use mac as pac
  Unresolved question: what visibility to attach to these macros, in other words - how far can they be reexported with pub use?
  Proposal: treat #[macro_export] macro_rules! { ... } as pub, treat other macro_rules! { ... } as pub(crate).
  Motivation: 1) #[macro_export] are indeed visible from other crates, 2) non-#[macro_export] macros themselves are indeed potentially visible from the whole crate, it depends on the containing module whether to actually let them out or not (similarly to public items in private modules and their potential reexports).
• Built-in attributes, for example use inline.
  Issue: even if inline is reimported under some other name, e.g. use inline as my_inline, my_inline won't be treated as inline by the compiler. Even later stages of the compiler work with attributes at token level, not using resolution results. That's not good in general, ideally attributes should be lowered into some semantic form somewhere around AST -> HIR conversion.
  This means a compatibility hazard, for example #[my_repr(D)] fn f() {} would be accepted and ignored if attributes are treated syntactically (assuming use repr as my_repr), but would be an error if attributes are treated semantically based on their resolution.
  On the other hand, if use builtin_attr is still feature-gated, then things like use proc_macro (or use ignore as recently reported) will be feature gated as well (use imports in all namespaces, and proc_macro is not only a crate, but also a built-in attribute).
  Proposal: Allow imports of built-in attributes, but prohibit actually using names imported this way in attribute positions.
• Derive helper attributes registered by derive macros, for example use serde attribute registered by Serialize macro.
  Not fully implemented, so imports can never refer to them.
  Issue (once fully implemented): similarly to built-in attributes, derive helpers reimported under other name will be unrecognizable by their respective proc macros, because proc macros work at token level.
  Proposal: Allow imports of derive helper attributes, but prohibit actually using names imported this way in attribute positions.
• "Tool modules" in tool attributes, like rusfmt in rustfmt::skip.
  Issue: similarly to built-in attributes, tool modules reimported under other name will be unrecognizable by their respective tools, because tools work at token level.
  Proposal: Allow imports of tool modules, but prohibit actually using names imported this way in attribute paths.

[petrochenkov]

So, we need to either:

• decide on visibility of macro_rules and future-proofing of attribute re-imports, and stabilize everything, or
• do not decide and stabilize everything except for imports referring to macro_rules / built-in attributes / tool modules.

[petrochenkov]

#56759 implements suggestions for macro_rules and attribute import future-proofing.

[shepmaster]

* Built-in macros, for example `use env`.
  Currently an error due to some (fixable) implementation details of built-in macros.
  No known issues to resolve before stabilization (after the error is removed).

Is this progress being tracked somewhere else?

[petrochenkov]

@shepmaster

Is this progress being tracked somewhere else?

I don't think so.

The issue is that built-in macros use CrateNum::BuiltinMacros in its DefId and it cannot leave resolve without causing a bunch of ICEs (it's a hack in general).
They should probably use LOCAL_CRATE instead and CrateNum::BuiltinMacros should be removed.

[petrochenkov]

Made an issue for built-in macro imports - #61687.