-
Notifications
You must be signed in to change notification settings - Fork 13.7k
Closed
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) = true
while 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
cfg
want nested meta-item paths to be single-segment.So, looks like
fn name
should returnOption<Name>
and all its callers need to be taught to deal withNone
somehow - 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
cfg
issue specifically was fixed in #53893.