# Moving \`cfg(accessible)\` forward by narrowing down its scope(part of RFC2523)

**URL:** <https://internals.rust-lang.org/t/moving-cfg-accessible-forward-by-narrowing-down-its-scope-part-of-rfc2523/22373>\
**Category:** Uncategorized\
**Created:** [February 11, 2025, 1:28am UTC](https://internals.rust-lang.org/t/moving-cfg-accessible-forward-by-narrowing-down-its-scope-part-of-rfc2523/22373 "2025-02-11T01:28:07Z")\
**Posts on this page:** 6\
**Page:** 2

<div class="post-metadata">

**Author:** ![RalfJung](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ralfjung/32/2415_2.png) [@RalfJung](https://internals.rust-lang.org/u/RalfJung)\
**Post date:** [March 4, 2025, 5:18pm UTC](https://internals.rust-lang.org/t/moving-cfg-accessible-forward-by-narrowing-down-its-scope-part-of-rfc2523/22373/21 "2025-03-04T17:18:07Z")

</div>

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 `::`.

---

<div class="post-metadata">

**Author:** ![deltragon](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/deltragon/32/11813_2.png) [@deltragon](https://internals.rust-lang.org/u/deltragon)\
**Post date:** [March 4, 2025, 9:21pm UTC](https://internals.rust-lang.org/t/moving-cfg-accessible-forward-by-narrowing-down-its-scope-part-of-rfc2523/22373/22 "2025-03-04T21:21:18Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![petrochenkov](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/petrochenkov/32/2784_2.png) [@petrochenkov](https://internals.rust-lang.org/u/petrochenkov)\
**Post date:** [March 4, 2025, 10:54pm UTC](https://internals.rust-lang.org/t/moving-cfg-accessible-forward-by-narrowing-down-its-scope-part-of-rfc2523/22373/23 "2025-03-04T22:54:45Z")

</div>

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 `cfg`s).

I guess the only thing that we can do to make `cfg(accessible)` to work "immediately", like other `cfg`s, and not like a macro is something like

> [@CAD97](#):
>
> Theoretically, it could optimistically resolve to the external crate name, and register a requirement for that name to not become ambiguous later.

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.)

---

<div class="post-metadata">

**Author:** ![RalfJung](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ralfjung/32/2415_2.png) [@RalfJung](https://internals.rust-lang.org/u/RalfJung)\
**Post date:** [March 5, 2025, 11:27am UTC](https://internals.rust-lang.org/t/moving-cfg-accessible-forward-by-narrowing-down-its-scope-part-of-rfc2523/22373/24 "2025-03-05T11:27:39Z")

</div>

> [@petrochenkov](#):
>
> at cost of behaving like a macro and not like `cfg` (code coming from macros has more restrictions than code coming from `cfg`s).

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?

---

<div class="post-metadata">

**Author:** ![petrochenkov](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/petrochenkov/32/2784_2.png) [@petrochenkov](https://internals.rust-lang.org/u/petrochenkov)\
**Post date:** [March 12, 2025, 4:34pm UTC](https://internals.rust-lang.org/t/moving-cfg-accessible-forward-by-narrowing-down-its-scope-part-of-rfc2523/22373/25 "2025-03-12T16:34:43Z")

</div>

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](https://github.com/rust-lang/rust/pull/52234) 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"](https://github.com/rust-lang/rust/pull/53778#issuecomment-419224049) in the compiler. Upd: there's a checkbox for it in [Document name resolution. · Issue #568 · rust-lang/reference · GitHub](https://github.com/rust-lang/reference/issues/568).

---

<div class="post-metadata">

**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\
**Post date:** [September 3, 2026, 4:34pm UTC](https://internals.rust-lang.org/t/moving-cfg-accessible-forward-by-narrowing-down-its-scope-part-of-rfc2523/22373/26 "2026-09-03T16:34:47Z")

</div>

Closed on September 3, 2026, 4:34pm UTC

This topic was automatically closed 540 days after the last reply. New replies are no longer allowed.

[Previous page](https://internals.rust-lang.org/t/moving-cfg-accessible-forward-by-narrowing-down-its-scope-part-of-rfc2523/22373.md?page=1)
