-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Make #[cfg(version)] respect RUSTC_OVERRIDE_VERSION_STRING #141413
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
Some changes occurred in compiler/rustc_attr_parsing Some changes occurred in compiler/rustc_attr_data_structures |
r? jieyouxu |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Two things:
- A naming nit.
- Can you squash the commits into one? The second test commit doesn't need to be its own commit IMO.
@rustbot author |
(Also, feel free to |
f294432
to
fdaca73
Compare
@rustbot ready |
Thanks, EDIT: actually one sec |
fdaca73
to
8616237
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
@bors r+ rollup |
🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened. |
Make #[cfg(version)] respect RUSTC_OVERRIDE_VERSION_STRING The `#[cfg(version(...))]` feature is currently under-tested. Part of it is the difficulty that it is hard to write a test that never changes, while the version of the Rust compiler indeed *does* change. PR rust-lang#81468 added the first and so far only test of `#[cfg(version(...))]`'s functionality (there is one other test for the *syntax*, that also acts as feature gate). But that test uses a proc macro that parses the version: the text of the test doesn't contain the actual `#[cfg(version(...))]`. This PR makes `#[cfg(version(...))]` respect `RUSTC_OVERRIDE_VERSION_STRING`, added by PR rust-lang#124339, allowing us to virtually pin the rustc version and write tests from all directions against some specific version. The PR also adds a functional test of `#[cfg(version(...))]` that leverages `RUSTC_OVERRIDE_VERSION_STRING`. Pulled out of rust-lang#141137. Tracking issue: rust-lang#64796
Rollup of 8 pull requests Successful merges: - #140790 (Enable xray support for Mac) - #141405 (GetUserProfileDirectoryW is now documented to always store the size) - #141413 (Make #[cfg(version)] respect RUSTC_OVERRIDE_VERSION_STRING) - #141427 (Disable `triagebot`'s `glacier` handler) - #141429 (Dont walk into unsafe binders when emiting error for non-structural type match) - #141438 (Do not try to confirm non-dyn compatible method) - #141444 (Improve CONTRIBUTING.md grammar and clarity) - #141446 (Add 2nd Solaris target maintainer) r? `@ghost` `@rustbot` modify labels: rollup
Make #[cfg(version)] respect RUSTC_OVERRIDE_VERSION_STRING The `#[cfg(version(...))]` feature is currently under-tested. Part of it is the difficulty that it is hard to write a test that never changes, while the version of the Rust compiler indeed *does* change. PR rust-lang#81468 added the first and so far only test of `#[cfg(version(...))]`'s functionality (there is one other test for the *syntax*, that also acts as feature gate). But that test uses a proc macro that parses the version: the text of the test doesn't contain the actual `#[cfg(version(...))]`. This PR makes `#[cfg(version(...))]` respect `RUSTC_OVERRIDE_VERSION_STRING`, added by PR rust-lang#124339, allowing us to virtually pin the rustc version and write tests from all directions against some specific version. The PR also adds a functional test of `#[cfg(version(...))]` that leverages `RUSTC_OVERRIDE_VERSION_STRING`. Pulled out of rust-lang#141137. Tracking issue: rust-lang#64796
8616237
to
f3245e4
Compare
fixed the build failure after a rebase. |
@bors r+ |
Rollup of 6 pull requests Successful merges: - #141413 (Make #[cfg(version)] respect RUSTC_OVERRIDE_VERSION_STRING) - #141443 (make teach_help message for cast-before-pass-to-variadic more precise) - #141508 (bootstrap: clippy: set TESTNAME based on given paths) - #141512 (Avoid extra path trimming in method not found error) - #141530 (Added unstable feature doc comments to unstable book) - #141541 (Random nits) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #141413 - est31:cfg_version_env_var, r=jieyouxu Make #[cfg(version)] respect RUSTC_OVERRIDE_VERSION_STRING The `#[cfg(version(...))]` feature is currently under-tested. Part of it is the difficulty that it is hard to write a test that never changes, while the version of the Rust compiler indeed *does* change. PR #81468 added the first and so far only test of `#[cfg(version(...))]`'s functionality (there is one other test for the *syntax*, that also acts as feature gate). But that test uses a proc macro that parses the version: the text of the test doesn't contain the actual `#[cfg(version(...))]`. This PR makes `#[cfg(version(...))]` respect `RUSTC_OVERRIDE_VERSION_STRING`, added by PR #124339, allowing us to virtually pin the rustc version and write tests from all directions against some specific version. The PR also adds a functional test of `#[cfg(version(...))]` that leverages `RUSTC_OVERRIDE_VERSION_STRING`. Pulled out of #141137. Tracking issue: #64796
Pull out dedicated `cfg_version` syntax test from feature gate test Tracking issue: rust-lang#64796. Closes rust-lang#141452, as a follow-up to rust-lang#141413 (comment) (point 3 of that is probably too pedantic). The feature gate test was dual-purposing causing feature gate errors to distract from syntax exercises. `@rustbot` label +F-cfg_version r? `@est31`
Pull out dedicated `cfg_version` syntax test from feature gate test Tracking issue: rust-lang#64796. Closes rust-lang#141452, as a follow-up to rust-lang#141413 (comment) (point 3 of that is probably too pedantic). The feature gate test was dual-purposing causing feature gate errors to distract from syntax exercises. ``@rustbot`` label +F-cfg_version r? ``@est31``
Rollup merge of #141552 - jieyouxu:cfg-version-tests, r=est31 Pull out dedicated `cfg_version` syntax test from feature gate test Tracking issue: #64796. Closes #141452, as a follow-up to #141413 (comment) (point 3 of that is probably too pedantic). The feature gate test was dual-purposing causing feature gate errors to distract from syntax exercises. ``@rustbot`` label +F-cfg_version r? ``@est31``
The
#[cfg(version(...))]
feature is currently under-tested. Part of it is the difficulty that it is hard to write a test that never changes, while the version of the Rust compiler indeed does change.PR #81468 added the first and so far only test of
#[cfg(version(...))]
's functionality (there is one other test for the syntax, that also acts as feature gate). But that test uses a proc macro that parses the version: the text of the test doesn't contain the actual#[cfg(version(...))]
.This PR makes
#[cfg(version(...))]
respectRUSTC_OVERRIDE_VERSION_STRING
, added by PR #124339, allowing us to virtually pin the rustc version and write tests from all directions against some specific version.The PR also adds a functional test of
#[cfg(version(...))]
that leveragesRUSTC_OVERRIDE_VERSION_STRING
.Pulled out of #141137.
Tracking issue: #64796