In the 2015 edition, :: denotes the crate root (and external crates are "mounted" into the crate root with extern crate), so that doesn't fully solve the problem -- you could still be referring to a path in the current crate, even if it starts with ::.
2 Likes
Would it be an option to require a leading ::, and only allow cfg(accessible) in Rust 2018 and later? (I'm not aware if there's precedent for doing that.)
Would that even be feasible to implement?
1 Like
Simply restricting paths in cfg(accessible) to any subset (only starting with ::, or only external) won't help with anything.
All paths are effectively internal if we are doing name resolution properly, even those starting with ::.
The currently implemented cfg_accessible can already work with arbitrary paths, including internal ones, at cost of behaving like a macro and not like cfg (code coming from macros has more restrictions than code coming from cfgs).
I guess the only thing that we can do to make cfg(accessible) to work "immediately", like other cfgs, and not like a macro is something like
Instead of resolving the first path segment properly we use some hack, like looking it up in the list of names passed with --extern (including the implicit ones like std), which is available before the macro expansion start.
Then in the end we run the "time travel" prevention pass, which will ensure that the end resolution is the same as the initial one. (We already run such pass for all import and macro paths.)
4 Likes
Is there a good summary of what this cost means, in practiced, for usage of cfg(accessible)? Is that implementation future-compatible with eventually doing the two-pass approach with time travel prevention?
I don't think it's documented in the reference, but the list of complaints and linked issues at the bottom of resolve: Modularize crate-local `#[macro_export] macro_rules` by petrochenkov · Pull Request #52234 · rust-lang/rust · GitHub may give an idea.
Also you can search for "a conflict between a macro-expanded name and a less macro-expanded name" and "a conflict between a name from a glob import and a macro-expanded name" errors in the test suite for examples.
The set of restrictions that is put on code produced by macros is called "restricted shadowing" in the compiler. Upd: there's a checkbox for it in Document name resolution. · Issue #568 · rust-lang/reference · GitHub.