Repository navigation
#[cfg(...)] ignores namespace #53489
Description
Repro:
fn main() {
println!(" cfg(a) = {}", cfg!(a));
println!("cfg(something::a) = {}", cfg!(something::a));
}$ rustc --cfg 'a' 1.rs && ./1
cfg(a) = true
cfg(something::a) = true
$ rustc --cfg 'something::a' 1.rs && ./1
cfg(a) = true
cfg(something::a) = true
$ rustc --cfg 'what::a' 1.rs && ./1
cfg(a) = true
cfg(something::a) = truewhile I expected these should print true/false, false/true and false/false instead.
(Note: this also affects --print cfg which something::a is collapsed to a)
$ rustc -vV
rustc 1.30.0-nightly (33b923fd4 2018-08-18)
binary: rustc
commit-hash: 33b923fd44c5c5925e635815fce68bdf1f98740f
commit-date: 2018-08-18
host: x86_64-apple-darwin
release: 1.30.0-nightly
LLVM version: 7.0
Activity
eddyb commentedon Aug 19, 2018
What happens if you also have
cfg(a), does that interact withcfg(something::a)?[-]--print=cfg ignores namespace[/-][+]cfg(...) ignores namespace[/+][-]cfg(...) ignores namespace[/-][+]#[cfg(...)] ignores namespace[/+]kennytm commentedon Aug 19, 2018
@eddyb Oh no,
cfg(something::a)is the same ascfg(a). Edited the issue.kennytm commentedon Aug 19, 2018
This behavior exists since 1.27. On 1.26 or before,
#[cfg(module::path)]is simply a syntax error.petrochenkov commentedon Aug 19, 2018
This looks like an unintended side-effect of #50030 that allowed arbitrary paths in meta-items (including nested ones), but
fn name()for meta-items still returns the last segment ignoring everything else.cc @flip1995 @topecongiro
Most of attributes, including
cfgwant nested meta-item paths to be single-segment.So, looks like
fn nameshould returnOption<Name>and all its callers need to be taught to deal withNonesomehow - report an error, or pass it further, etc.eddyb commentedon Aug 19, 2018
I'd suggest having a flag on "meta-item parsing" to say whether it should allow paths at all - most of the builtin attributes don't need paths.
petrochenkov commentedon Oct 15, 2018
The
cfgissue specifically was fixed in #53893.