-
Notifications
You must be signed in to change notification settings - Fork 13.3k
compiletest: add a proper supports-crate-type: xxx
directive
#132309
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
A-compiletest
Area: The compiletest test runner
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
E-medium
Call for participation: Medium difficulty. Experience needed to fix: Intermediate.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Comments
Related: #132350 |
supports-crate-type: dylib
directive supports-crate-type: xxx
directive
This was referenced Jan 8, 2025
3 tasks
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Apr 7, 2025
…type, r=<try> Introduce a `//@ needs-crate-type` compiletest directive > [!CAUTION] > > Blocked on bootstrap compiler bump rust-lang#139279 so I can get rid of the `cfg(not(bootstrap))` on the compiletest directive unit test. The `//@ needs-crate-type: $crate_types...` directive takes a comma-separated list of crate types that the target platform must support in order for the test to be run. This allows the test writer to semantically convey that the ignore condition is based on target crate type needs, instead of using a general purpose `//@ ignore-$target` directive (often without comment). Fixes rust-lang#132309. ### Example ```rs //@ needs-crate-type: dylib (ignored on e.g. wasm32-unknown-unknown) //@ compile-flags: --crate-type=dylib fn foo() {} ``` ### Review advice - Best reviewed commit-by-commit. - The impl is not very clean, I briefly attempted to clean up the directive handling but found that more invasive changes are needed, so I'd like to not block on the cleanup for now. try-job: test-various try-job: armhf-gnu
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Apr 11, 2025
Rollup merge of rust-lang#139469 - jieyouxu:compiletest-supports-crate-type, r=onur-ozkan Introduce a `//@ needs-crate-type` compiletest directive The `//@ needs-crate-type: $crate_types...` directive takes a comma-separated list of crate types that the target platform must support in order for the test to be run. This allows the test writer to semantically convey that the ignore condition is based on target crate type needs, instead of using a general purpose `//@ ignore-$target` directive (often without comment). Fixes rust-lang#132309. ### Example ```rs //@ needs-crate-type: dylib (ignored on e.g. wasm32-unknown-unknown) //@ compile-flags: --crate-type=dylib fn foo() {} ``` ### Review advice - Best reviewed commit-by-commit. - The impl is not very clean, I briefly attempted to clean up the directive handling but found that more invasive changes are needed, so I'd like to not block on the cleanup for now. try-job: test-various try-job: armhf-gnu
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-compiletest
Area: The compiletest test runner
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
E-medium
Call for participation: Medium difficulty. Experience needed to fix: Intermediate.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Apparently
needs-dynamic-linking
is not equivalent to checking if dylib or cdylib crate types are supported.needs-dynamic-linking
performs a check based on target cfg'sdynamic_linking
field +--print=cfg --target $TARGET
.only_cdylib
which, ifdynamic_linking
istrue
, indicates that onlycdylib
crate type is supported and notdylib
.rust/compiler/rustc_target/src/spec/mod.rs
Lines 2148 to 2153 in f2becdf
wasm
base, dynamic linking is supported but notdylib
crate type, onlycdylib
is supported.rust/compiler/rustc_target/src/spec/base/wasm.rs
Lines 58 to 62 in f2becdf
Originally posted by @jieyouxu in #130860 (comment)
The text was updated successfully, but these errors were encountered: