-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
bootstrap: don't use rustflags for --rustc-args
#128841
Conversation
We had an issue with setting --rustc-args for any test (which is also needed). We could add another flag specifically for handling |
Yeah I linked to that issue in the PR description. The way it was fixed broke the flag that had existed for compiletests. Maybe there could be a dedicated flag for these other tests, or they can use rustflags. We can’t do that for compiletests. |
We don’t have any - right, using
Can't we replace cc @RalfJung |
That's what I did in the PR to change the std size-optimized tests, but I'm not sure if it'd work exactly in the same way for miri tests, in particular I wanted to avoid possibly breaking use-cases or CI they might have relying on Maybe an alternative is making sure Maybe renaming to |
I don't know --rustc-args and whatever it does in ./x.py miri is likely copied from somewhere else without understanding what the flag is supposed to do. Feel free to change its behavior in any way you see fit.
|
Let's do that before landing this. |
Ok. I'll also try to do some archeology on |
I can assure you it exists only by copying -- adding We usually use the MIRIFLAGS env var to pass flags to Miri with |
to pick up changes to `./x miri` and `./x test` commands
Done, I've renamed the flag as you asked. I've also removed |
This PR modifies If appropriate, please update Some changes occurred in compiler/rustc_codegen_gcc |
Context for the last ping: |
@bors r+ |
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#128643 (Refactor `powerpc64` call ABI handling) - rust-lang#128655 (std: refactor UNIX random data generation) - rust-lang#128745 (Remove unused lifetime parameter from spawn_unchecked) - rust-lang#128841 (bootstrap: don't use rustflags for `--rustc-args`) - rust-lang#128983 (Slightly refactor `TargetSelection` in bootstrap) - rust-lang#129026 (CFI: Move CFI ui tests to cfi directory) - rust-lang#129040 (Fix blessing of rmake tests) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#128841 - lqd:rustc-args, r=onur-ozkan bootstrap: don't use rustflags for `--rustc-args` r? `@onur-ozkan` This is going to require a bit of context. rust-lang#47558 has added `--rustc-args` to `./x test` to allow passing flags when building `compiletest` tests. It was made specifically because using `RUSTFLAGS` would rebuild the compiler/stdlib, which would in turn require the flag you want to build tests with to successfully bootstrap. rust-lang#113178 made the request that it also works for other tests and doctests. This is not trivial to support across the board for `library`/`compiler` unit-tests/doctests and across stages. This issue was closed in rust-lang#113948 by using `RUSTFLAGS`, seemingly incorrectly since rust-lang#123489 fixed that part to make it work. Unfortunately rust-lang#123489/rust-lang#113948 have regressed the goals of `--rustc-args`: - now we can't use rustc args that don't bootstrap, to run the UI tests: we can't test incomplete features. The new trait solver doesn't bootstrap, in-progress borrowck/polonius changes don't bootstrap, some other features are similarly incomplete, etc. - using the flag now rebuilds everything from scratch: stage0 stdlib, stage1 compiler, stage1 stdlib. You don't need to re-do all this to compile UI tests, you only need the latter to run stdlib tests with a new flag, etc. This happens for contributors, but also on CI today. (Not to mention that in doing that it will rebuild things with flags that are not meant to be used, e.g. stdlib cfgs that don't exist in the compiler; or you could also imagine that this silently enables flags that were not meant to be enabled in this way). Since then, rust-lang@bd71c71 has started using it to test a stdlib feature, relying on the fact that it now rebuilds everything. So rust-lang#125011 also regressed CI times more than necessary because it rebuilds everything instead of just stage 1 stdlib. It's not easy for me to know how to properly fix rust-lang#113178 in bootstrap, but rust-lang#113948/rust-lang#123489 are not it since they regress the initial intent. I'd think bootstrap would have to know from the list of test targets that are passed that the `library` or `compiler` paths that are passed could require rebuilding these crates with different rustflags, probably also depending on stages. Therefore I would not be able to fix it, and will just try in this PR to unregress the situation to unblock the initial use-case. It seems miri now also uses `./x miri --rustc-args` in this incorrect meaning to rebuild the `library` paths they support to run with the new args. I've not made any bootstrap changes related to `./x miri` in this PR, so `--rustc-args` wouldn't work there anymore. I'd assume this would need to use rustflags again but I don't know how to make that work properly in bootstrap, hence opening as draft, so you can tell me how to do that. I assume we don't want to break their use-case again now that it exists, even though there are ways to use `./x test` to do exactly that. `RUSTFLAGS_NOT_BOOTSTRAP=flag ./x test library/std` is a way to run unit tests with a new flag without rebuilding everything, while with rust-lang#123489 there is no way anymore to run tests with a flag that doesn't bootstrap. --- edit: after review, this PR: - renames `./x test --rustc-args` to `./x test --compiletest-rustc-args` as it only applies there, and cannot use rustflags for this purpose. - fixes the regression that using these args rebuilt everything from scratch - speeds up some CI jobs via the above point - removes `./x miri --rustc-args` as only library tests are supported, needs to rebuild libstd, and `./x miri --compiletest-rustc-args` wouldn't work since compiletests are not supported.
Here are all the changes. I went through them one-by-one and confirmed that they should not be affecting us. In paritcular, we explicitly set rust.lld = false (because we want to use the lld that ships with clang), so the change in default does not affect us. There have been changes to x.py since you last updated: [INFO] New option `build.lldb` that will override the default lldb binary path used in debuginfo tests - PR Link rust-lang/rust#124501 [INFO] The compiler profile now defaults to rust.debuginfo-level = "line-tables-only" - PR Link rust-lang/rust#123337 [WARNING] `rust.lld` has a new default value of `true` on `x86_64-unknown-linux-gnu`. Starting at stage1, `rust-lld` will thus be this target's default linker. No config changes should be necessary. - PR Link rust-lang/rust#124129 [WARNING] Removed `dist.missing-tools` configuration as it was deprecated long time ago. - PR Link rust-lang/rust#125535 [WARNING] `llvm.lld` is enabled by default for the dist profile. If set to false, `lld` will not be included in the dist build. - PR Link rust-lang/rust#126701 [WARNING] `debug-logging` option has been removed from the default `tools` profile. - PR Link rust-lang/rust#127913 [INFO] the `wasm-component-ld` tool is now built as part of `build.extended` and can be a member of `build.tools` - PR Link rust-lang/rust#127866 [INFO] Removed android-ndk r25b support in favor of android-ndk r26d. - PR Link rust-lang/rust#120593 [WARNING] For tarball sources, default value for `rust.channel` will be taken from `src/ci/channel` file. - PR Link rust-lang/rust#125181 [INFO] New option `llvm.libzstd` to control whether llvm is built with zstd support. - PR Link rust-lang/rust#125642 [WARNING] ./x test --rustc-args was renamed to --compiletest-rustc-args as it only applies there. ./x miri --rustc-args was also removed. - PR Link rust-lang/rust#128841 [INFO] The `build.profiler` option now tries to use source code from `download-ci-llvm` if possible, instead of checking out the `src/llvm-project` submodule. - PR Link rust-lang/rust#129295 Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/infra/recipes/+/1120078 Original-Revision: 27df37a30e50b14b9ffefc872b6997790f03d4ea GitOrigin-RevId: 341e222f002e36886b9960645b21faeaed633f90 Change-Id: Id1eb54a677a6f538bf7666d65b85d5fdba17ea42
r? @onur-ozkan
This is going to require a bit of context.
#47558 has added
--rustc-args
to./x test
to allow passing flags when buildingcompiletest
tests. It was made specifically because usingRUSTFLAGS
would rebuild the compiler/stdlib, which would in turn require the flag you want to build tests with to successfully bootstrap.#113178 made the request that it also works for other tests and doctests. This is not trivial to support across the board for
library
/compiler
unit-tests/doctests and across stages. This issue was closed in #113948 by usingRUSTFLAGS
, seemingly incorrectly since #123489 fixed that part to make it work.Unfortunately #123489/#113948 have regressed the goals of
--rustc-args
:Since then, bd71c71 has started using it to test a stdlib feature, relying on the fact that it now rebuilds everything. So #125011 also regressed CI times more than necessary because it rebuilds everything instead of just stage 1 stdlib.
It's not easy for me to know how to properly fix #113178 in bootstrap, but #113948/#123489 are not it since they regress the initial intent. I'd think bootstrap would have to know from the list of test targets that are passed that the
library
orcompiler
paths that are passed could require rebuilding these crates with different rustflags, probably also depending on stages. Therefore I would not be able to fix it, and will just try in this PR to unregress the situation to unblock the initial use-case.It seems miri now also uses
./x miri --rustc-args
in this incorrect meaning to rebuild thelibrary
paths they support to run with the new args. I've not made any bootstrap changes related to./x miri
in this PR, so--rustc-args
wouldn't work there anymore. I'd assume this would need to use rustflags again but I don't know how to make that work properly in bootstrap, hence opening as draft, so you can tell me how to do that. I assume we don't want to break their use-case again now that it exists, even though there are ways to use./x test
to do exactly that.RUSTFLAGS_NOT_BOOTSTRAP=flag ./x test library/std
is a way to run unit tests with a new flag without rebuilding everything, while with #123489 there is no way anymore to run tests with a flag that doesn't bootstrap.edit: after review, this PR:
./x test --rustc-args
to./x test --compiletest-rustc-args
as it only applies there, and cannot use rustflags for this purpose../x miri --rustc-args
as only library tests are supported, needs to rebuild libstd, and./x miri --compiletest-rustc-args
wouldn't work since compiletests are not supported.