Move configuration 1 phase before crate metadata collection#25399
Move configuration 1 phase before crate metadata collection#25399bors merged 1 commit intorust-lang:masterfrom
Conversation
|
r? @pcwalton (rust_highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
Could this be included as a run-pass test instead? You could have an auxiliary file which uses conditional compilation to build a library and then also have a binary which uses conditional compilation to build itself as a binary instead (using // compile-flags to pass --cfg flags).
There was a problem hiding this comment.
I wasn't quite sure how to make a run-pass test, but I've never actually looked at the auxiliary folder before so I wasn't really aware of how to do that. I'll try that now.
and then also have a binary which uses conditional compilation to build itself as a binary instead
What do you mean? Doesn't rustc assume it's a binary by default if not otherwise specified? I don't see how I can specify a file that would build as a library by default and override it to a binary with an attribute (since --crate-type on the command-line overrides #![crate_type]).
There was a problem hiding this comment.
Ah I think an auxiliary file won't actually work due to the compiler passing --crate-type, but this should work as a run-pass test because the compiler only assumes a binary output if no other is specified:
// src/test/run-pass/foo.rs
// compile-flags: --cfg foo
#![crate_type = "lib"]
#![cfg_attr(foo, crate_type = "bin")]
fn main() {}There was a problem hiding this comment.
I checked compiletest and it skips --crate-type if the auxiliary file specifies // no-prefer-dynamic (although I don't know why it doesn't just fall back to lib in that case). I could use the duplicate crate_type attributes like that but it results in a warning about the first one being unused.
There was a problem hiding this comment.
Still, I suppose the warning is benign. It would be simpler to not have an auxiliary file.
There was a problem hiding this comment.
Oh huh, it's actually building both a binary and a library. I swear I tried this before and got a warning.
There was a problem hiding this comment.
That said, it doesn't work as a run-pass, because building two files like that doesn't seem to work with the -o flag (based on the error message, it seems to always result in the specified output path being the library).
|
Looks good to me, thanks! r=me with a switch to a run-pass instead of a run-make test. |
Stripping unconfigured items prior to collecting crate metadata means we can say things like `#![cfg_attr(foo, crate_type="lib")]`. Fixes rust-lang#25347.
lilyball
force-pushed
the
crate-attributes-cfg_attr
branch
from
070d6b3 to
90b9529
Compare
|
@bors r=alexcrichton |
|
📌 Commit 90b9529 has been approved by |
…hton Stripping unconfigured items prior to collecting crate metadata means we can say things like `#![cfg_attr(foo, crate_type="lib")]`. Fixes #25347.
|
⌛ Testing commit 90b9529 with merge 2792855... |
|
This isn't a total fix since some attributes like |
|
@sfackler Good point, though Which is to say, I can readily believe that |
|
Filed #25544 for |
7 participants
Stripping unconfigured items prior to collecting crate metadata means we
can say things like
#![cfg_attr(foo, crate_type="lib")].Fixes #25347.