Repository navigation
Conversation
|
The rustc-dev-guide subtree was changed. If your future PRs only touch the subtree, consider submitting them directly to rust-lang/rustc-dev-guide, which is where the document is primarily maintained (and has faster CI). Some changes occurred in src/tools/compiletest cc @jieyouxu |
This comment has been minimized.
This comment has been minimized.
80eb9e2 to
9565273
Compare
|
You can probably remove rust/compiler/rustc_codegen_cranelift/scripts/test_rustc_tests.sh Lines 162 to 167 in c165834 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
9565273 to
a36b6f8
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
a36b6f8 to
8e072e8
Compare
This comment has been minimized.
This comment has been minimized.
8e072e8 to
0c3b3be
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
| /// Specifically, we need it when we want to test how rustc behaves on the stable channel, | ||
| /// but at the same time we need to be able to pass it some unstable `-Z` compiler flags | ||
| /// required for the testing infrastructure itself to work. | ||
| ActAsStableForTesting, |
There was a problem hiding this comment.
I feel like this name isn't very intuitive -- if we can use unstable compiler flags then we are not acting as stable. I would directly call this AllowUnstableCompilerFlagsOnly as opposed to ActAsStableForTesting. WDYT?
In the sense that, we actually have three aspects:
- Release channel: stable/beta vs nightly
- Can unstable language features be used
- Can unstable compiler flags be used
Ditto on the comment below
There was a problem hiding this comment.
Makes sense, I'll rename it.
| // `RUSTC_BOOTSTRAP=-2` simulates the stable toolchain, while allowing unstable compiler flags | ||
| // to be passed. | ||
| std::assert_matches!( | ||
| UnstableFeatures::from_environment_value(None, Ok("-2".to_string())), | ||
| UnstableFeatures::ActAsStableForTesting | ||
| ); |
There was a problem hiding this comment.
I wonder, technically I think we can call this -allow-unstable-compiler-flags right, doesn't have to be 2? Because sure --crate-name accepts a wide range of identifiers but -<whatever> is not a valid crate name.
| To test stable-only behavior, use the `act-as-stable` directive, which will set `RUSTC_BOOTSTRAP=-2` | ||
| for you. |
There was a problem hiding this comment.
This should also mention allow using unstable compiler flags but not unstable features
| /// a best-effort approximation for diagnostics. Add new directives to this list when needed. | ||
| pub(crate) const KNOWN_DIRECTIVE_NAMES: &[&str] = &[ | ||
| // tidy-alphabetical-start | ||
| "act-as-stable", |
There was a problem hiding this comment.
So I don't love the name, because it's actually more like //@ well-actually-we-allow-unstable-compiler-flags-but-not-language-features. But obviously that's a despairingly long name...
There's candidates like
//@ pretend-stable(which is really the same meaning asact-as-stable)//@ stable-features-only, but that loses the "pretend" intent
Maybe //@ act-as-stable is fine.
| }; | ||
|
|
||
| if !edition.is_stable() && !nightly_options::is_unstable_enabled(matches) { | ||
| if !edition.is_stable() && !nightly_options::unstable_options_enabled(matches) { |
There was a problem hiding this comment.
Nit: grepping shows that there's still a reference to unstable_options_enabled around 516
| handler(ACT_AS_STABLE, |_config, ln, props| { | ||
| if ln.name == ACT_AS_STABLE { | ||
| // Simulate the stable toolchain, but allow unstable -Z flags passed by compiletest | ||
| props.rustc_env.push(("RUSTC_BOOTSTRAP".to_string(), "-2".to_string())); | ||
| } | ||
| }), |
There was a problem hiding this comment.
Can we reject using this outside of ui mode as well?
(NB: I know we need to improve how we handle which directives are rejected/accepted under which conditions, but not in this PR.)
| let print_help = || { | ||
| // Only show unstable options in --help if we accept unstable options. | ||
| let unstable_enabled = nightly_options::is_unstable_enabled(&matches); | ||
| let unstable_enabled = nightly_options::unstable_options_enabled(&matches); |
There was a problem hiding this comment.
This is actually changing the help output, I wouldn't expect the "act-as-stable" mode to do that.
FWIW, I like the "less principled escape hatch" alternative better.
Accepting all unstable flags deviates too much from acting as stable, and we don't actually need all unstable flags for UI testing, only like 2-3 of them.
There was a problem hiding this comment.
Yeah, if we are able to limit it to only for-testing ones, that seems generally better.
There was a problem hiding this comment.
I was also thinking about that. Maybe we could do RUSTC_BOOTSTRAP=-allow-unstable-compiler-flags=ui-testing,second-flag-that-compiletest-needs, etc.? One issue with that is that compiletest actually passes also -Zunstable-options, IIRC, which increases the blast radius of the "stable-like" behavior that we change in those tests.
…mpiler-flags=<flags>`
|
I reimplemented the flag as |
RUSTC_BOOTSTRAP=-2 mode for testing stable compiler behavior in UI testsRUSTC_BOOTSTRAP=-allow-unstable-compiler-flags mode for testing stable compiler behavior in UI tests
This comment has been minimized.
This comment has been minimized.
247506c to
ea39d9a
Compare
This comment has been minimized.
This comment has been minimized.
ea39d9a to
adbf2a5
Compare
View all comments
Right now, it is not possible to test how the compiler behaves on the stable toolchain in UI tests. Even though #132993 added a mechanism to emulate stable rustc on the nightly channel, using the
RUSTC_BOOTSTRAP=-1environment variable, this mechanism is not currently usable within compiletest and UI tests directly, because compiletest unconditionally passes several unstable-Zflags that are load-bearing for the testing infra itself to work (notably-Zui-testingand friends).That is quite annoying, because we do in fact want to test stable behavior in a couple of tests, but today we have to write those as
run-maketests (latest example: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Testing.20stable.20vs.20nightly.20behavior.20in.20UI.20tests/with/628206707), even if the tested situation is very simple. Those are harder to read, write and maintain than UI tests and they do not support blessing outputs as well as UI tests. Recently, I at least added #163444 as a way of centralizing the logic of testing a stablerustcin a run-make test, but that does not really help with the fact that we still have to use run-make tests for it, even when a normal UI test would do.For #162848, I would also like to have a way of passing
-Zthreads=1to all run-make tests, even if they are testing stablerustc, but that's not easily possible, because those tests are usingRUSTC_BOOTSTRAP=-1.This PR proposes to add a new mode to
RUSTC_BOOTSTRAP, with the value of-allow-unstable-compiler-flags=<flags>. This can be used to emulate the behavior of stable rustc, while still allowing passing specific unstable flags to the compiler.The stability check in the compiler is thus now separated into two questions:
The latter is checked only at a few places, so the necessary change to the compiler is rather small (IMO).
To demonstrate how this would be used, I also implemented a new directive into compiletest in this PR,
act-as-stable. That can be used in a UI test to emulate stable rustc. Some tests before usedonly-stableto "achieve" this, which is very misleading, because it doesn't work at all 😆, due to compiletest unconditionally passingRUSTC_BOOTSTRAP=1to all executed tests.act-as-stablefixes that.The last two commits demonstrate how we could replace run-make tests that tested different output on stable/nightly with UI tests.
I suppose that this mode might be interesting for other people outside of
rust-lang/rust, but if you don't want that, I can gate it behind-Zui-testing.r? jieyouxu