Fix command trace
With the recent developments in centralization of command execution, we somehow broke the traces for command execution. This PR fixes that and add trace to stream command execution as well.
r? ````@Kobzol````
clippy: fix test filtering when TESTNAME is empty
Fixes https://github.com/rust-lang/rust/issues/143824. Turns out bootstrap was just fine, the TESTNAME logic in clippy was wrong... I still made this a rustc PR as that's where I did all the debugging.
The bootstrap change is not really related, but it's comment-only so not worth a separate PR... adding the `test_args` is also part of what `prepare_cargo_test` would usually do so let's group the code properly.
Fix fallback for CI_JOB_NAME
If CI_JOB_NAME is not specified, it's supposed to fall back to the image name, which is `$image`, not `$IMAGE`.
Failing to set the correct CI_JOB_NAME causes failures when running `dist-ohos-*` images locally.
Add --compile-time-deps argument for x check
Together with skipping building C++ code in rustc_llvm for check, this reduces the amount of time it takes to do the x check for rust-analyzer analysis from 12m16s to 3m06s when the bootstrap compiler is already downloaded.
interpret/allocation: expose init + write_wildcards on a range
Part of https://github.com/rust-lang/miri/pull/4456, so that we can mark down when a foreign access to our memory happened. Should this also move `prepare_for_native_access()` itself into Miri, given that everything there can be implemented on Miri's side?
r? `````@RalfJung`````
Rollup of 12 pull requests
Successful merges:
- rust-lang/rust#143776 (std: move NuttX to use arc4random for random number generation)
- rust-lang/rust#143778 (Some const_trait_impl test cleanups)
- rust-lang/rust#143782 (Disambiguate between rustc vs std having debug assertions in `run-make-support` and `run-make` tests)
- rust-lang/rust#143791 (Update sysinfo version to `0.36.0`)
- rust-lang/rust#143796 (Fix ICE for parsed attributes with longer path not handled by CheckAttribute)
- rust-lang/rust#143798 (Remove format short command trait)
- rust-lang/rust#143803 (New tracking issues for const_ops and const_cmp)
- rust-lang/rust#143814 (htmldocck: better error messages for some negative directives)
- rust-lang/rust#143817 (Access `wasi_sdk_path` instead of reading environment variable in bootstrap)
- rust-lang/rust#143822 (./x test miri: fix cleaning the miri_ui directory)
- rust-lang/rust#143823 ([COMPILETEST-UNTANGLE 5/N] Test mode adjustments and other assorted cleanups)
- rust-lang/rust#143841 (Label clippy changes with `T-clippy`)
Failed merges:
- rust-lang/rust#143850 (Compiletest: Simplify {Html,Json}DocCk directive handling)
r? `@ghost`
`@rustbot` modify labels: rollup
[COMPILETEST-UNTANGLE 5/N] Test mode adjustments and other assorted cleanups
This is part of a patch series to untangle `compiletest` to hopefully nudge it towards being more maintainable.
This PR should contain no functional changes modulo the removed debugger version warning.
- Commit 1: Removes a very outdated debugger version warning.
- Commit 2: Moves `string_enum` out of `common` into `util` module.
- Commit 3: Remove `#[derive(Default)` for `Mode` and `Config`. It is very important for correctness that we *don't* `#[derive(Default)]`, because there are no sensible defaults, so stop pretending there is.
- Commit 4: Rename `Mode` -> `TestMode`, because I would like to introduce a `TestSuite` enum to stop using stringly-typed test suite names where test mode names can be the same as test suite names, and we also have a bunch of other "modes" in compiletest. Make this as unambiguous as possible. A corollary is that now it's more natural to reference via intra-doc links as ``[`TestMode`]``.
- Commit 5: Ditto on `TestSuite`, stop glob-reexporting `TestMode::*` variants, and always use `EnumName::VariantName` form.
- Commit 6: Apparently, `src/tools/rustdoc-gui-test/` depends on `compiletest` for `//@ {compile,run}-paths` directive parsing and extraction, which involves creating a dummy `compiletest` config (hence the existence of the default impls removed in Commit 3). Make this a specific associated function with a FIXME pointing to rust-lang/rust#143827 as I think this setup is quite questionable.
Commits {4, 5} are also intended to help improve the self-consistency in nomenclature used within compiletest.
Best reviewed commit-by-commit.
Access `wasi_sdk_path` instead of reading environment variable in bootstrap
Small cleanup to remove an environment variable read that we have performed earlier in bootstrap already.
htmldocck: better error messages for some negative directives
Previously it was saying "did not match pattern" even when the error was that it did match the pattern, and it wasn't supposed to.
Remove format short command trait
Since we no longer have traces of the vanilla command, and we're already implementing format_short_command for CommandFingerprint, we can use it directly from the fingerprint. This PR removes the standalone format_short_command trait and moves its implementation under CommandFingerprint.
Disambiguate between rustc vs std having debug assertions in `run-make-support` and `run-make` tests
`NO_DEBUG_ASSERTIONS` is set by CI that threads through to the `./configure.py` script, which is somewhat fragile and "spooky action at a distance". For `fmt-write-bloat`, this is actually wrong because the test wants to gate on *std* being built with debug assertions or not, whereas `NO_DEBUG_ASSERTIONS` determines *rustc* being built with debug assertions or not. Instead, use env vars controlled by compiletest, whose debug assertion info comes from bootstrap.
855e0fe46e/src/ci/run.sh (L137-L146)
`NO_DEBUG_ASSERTIONS` controls `--enable-debug-assertions`
855e0fe46e/src/bootstrap/configure.py (L124)
which sets `--rust.debug-assertions`, which controls *rustc* debug assertions.
855e0fe46e/src/bootstrap/configure.py (L125-L129)
`--rust.debug-assertions-std` controls *std* debug assertions.
Noticed while investigating `fmt-write-bloat` in https://github.com/rust-lang/rust/pull/143669#discussion_r2200522215.
Best reviewed commit-by-commit.
r? ``@ChrisDenton`` (or compiler/bootstrap)
de-duplicate condition scoping logic between AST→HIR lowering and `ScopeTree` construction
There was some overlap between `rustc_ast_lowering::LoweringContext::lower_cond` and `rustc_hir_analysis::check::region::resolve_expr`, so I've removed the former and migrated its logic to the latter, with some simplifications.
Consequences:
- For `while` and `if` expressions' `let`-chains, this changes the `HirId`s for the `&&`s to properly correspond to their AST nodes. This is how guards were handled already.
- This makes match guards share previously-duplicated logic with `if`/`while` expressions. This will also be used by guard pattern[^1] guards.
- Aside from legacy syntax extensions (e.g. some builtin macros) that directly feed AST to the compiler, it's currently impossible to put attributes directly on `&&` operators in `let` chains[^2]. Nonetheless, attributes on `&&` operators in `let` chains in `if`/`while` expression conditions are no longer silently ignored and will be lowered.
- This no longer wraps conditions in `DropTemps`, so the HIR and THIR will be slightly smaller.
- `DesugaringKind::CondTemporary` is now gone. It's no longer applied to any spans, and all uses of it were dead since they were made to account for `if` and `while` being desugared to `match` on a boolean scrutinee.
- Should be a marginal perf improvement beyond that due to leveraging [`ScopeTree` construction](5e749eb66f/compiler/rustc_hir_analysis/src/check/region.rs (L312-L355))'s clever handling of `&&` and `||`:
- This removes some unnecessary terminating scopes that were placed around top-level `&&` and `||` operators in conditions. When lowered to MIR, logical operator chains don't create intermediate boolean temporaries, so there's no temporary to drop. The linked snippet handles wrapping the operands in terminating scopes as necessary, in case they create temporaries.
- The linked snippet takes care of letting `let` temporaries live and terminating other operands, so we don't need separate traversals of `&&` chains for that.
[^1]: rust-lang/rust#129967
[^2]: Case-by-case, here's my justification: `#[attr] e1 && e2` applies the attribute to `e1`. In `#[attr] (e1 && e2)` , the attribute is on the parentheses in the AST, plus it'd fail to parse if `e1` or `e2` contains a `let`. In `#[attr] expands_to_let_chain!()`, the attribute would already be ignored (rust-lang/rust#63221) and it'd fail to parse anyway; even if the expansion site is a condition, the expansion wouldn't be parsed with `Restrictions::ALLOW_LET`. If it *was* allowed, the notion of a "reparse context" from https://github.com/rust-lang/rust/issues/61733#issuecomment-509626449 would be necessary in order to make `let`-chains left-associative; multiple places in the compiler assume they are.
Split up the `unknown_or_malformed_diagnostic_attributes` lint
This splits up the lint into the following lint group:
- `unknown_diagnostic_attributes` - triggers if the attribute is unknown to the current compiler
- `misplaced_diagnostic_attributes` - triggers if the attribute exists but it is not placed on the item kind it's meant for
- `malformed_diagnostic_attributes` - triggers if the attribute's syntax or options are invalid
- `malformed_diagnostic_format_literals` - triggers if the format string literal is invalid, for example if it has unpaired curly braces or invalid parameters
- this pr doesn't create it, but future lints for things like deprecations can also go here.
This PR does not start emitting lints in places that previously did not.
## Motivation
I want to have finer control over what `unknown_or_malformed_diagnostic_attributes` does
I have a project with fairly low msrv that is/will have a lower msrv than future diagnostic attributes. So lints will be emitted when I or others compile it on a lower msrv.
At this time, there are two options to silence these lints:
- `#[allow(unknown_or_malformed_diagnostic_attributes)]` - this risks diagnostic regressions if I (or others) mess up using the attribute, or if the attribute's syntax ever changes.
- write a build script to detect the compiler version and emit cfgs, and then conditionally enable the attribute:
```rust
#[cfg_attr(rust_version_99, diagnostic::new_attr_in_rust_99(thing = ..))]`
struct Foo;
```
or conditionally `allow` the lint:
```rust
// lib.rs
#![cfg_attr(not(current_rust), allow(unknown_or_malformed_diagnostic_attributes))]
```
I like to avoid using build scripts if I can, so the following works much better for me. That is what this PR will let me do in the future:
```rust
#[allow(unknown_diagnostic_attribute, reason = "attribute came out in rust 1.99 but msrv is 1.70")]
#[diagnostic::new_attr_in_rust_99(thing = ..)]`
struct Foo;
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#143403 (Port several trait/coherence-related attributes the new attribute system)
- rust-lang/rust#143633 (fix: correct assertion to check for 'noinline' attribute presence before removal)
- rust-lang/rust#143647 (Clarify and expand documentation for std::sys_common dependency structure)
- rust-lang/rust#143716 (compiler: doc/comment some codegen-for-functions interfaces)
- rust-lang/rust#143747 (Add target maintainer information for aarch64-unknown-linux-musl)
- rust-lang/rust#143759 (Fix typos in function names in the `target_feature` test)
- rust-lang/rust#143767 (Bump `src/tools/x` to Edition 2024 and some cleanups)
- rust-lang/rust#143769 (Remove support for SwitchInt edge effects in backward dataflow)
- rust-lang/rust#143770 (build-helper: clippy fixes)
r? `@ghost`
`@rustbot` modify labels: rollup
I would like to introduce `TestSuite` over stringly-typed test suite
names, and some test suite names are the same as test modes, which can
make this very confusing.
It is *critical* that we maintain clear nomenclature in `compiletest`.
We have many types of "modes" in `compiletest` -- pass modes, coverage
modes, compare modes, you name it. `Mode` is also a *super* general
term. Rename it to `TestMode` to leave no room for such ambiguity.
As a follow-up, I also intend to introduce an enum for `TestSuite`, then
rid of all usage of glob re-exported `TestMode::*` enum variants -- many
test suites share the same name as the test mode.
Add target maintainer information for aarch64-unknown-linux-musl
Mentioning ``@famfo`` so that they can review the documentation. We're both very invested in this target; I originally promoted it to tier 2 with host tools in rust-lang/rust#76420 back in 2020.
If CI_JOB_NAME is not specified, it's supposed to fall back to
the image name, which is `$image`, not `$IMAGE`.
Failing to set the correct CI_JOB_NAME causes failures when running
`dist-ohos-*` images locally.
This reduces the amount of time it takes to do the x check for
rust-analyzer analysis from 12m16s to 3m34s when the bootstrap compiler
is already downloaded.
Additionally, `NO_DEBUG_ASSERTIONS` is set by CI that threads through to
the `./configure` script, which is somewhat fragile and "spooky action
at a distance". Instead, use env vars controlled by compiletest, whose
debug assertion info comes from bootstrap.
fix: Include frontmatter in -Zunpretty output
In the implementation (rust-lang/rust#140035), this was left as an open question for
the tracking issue (rust-lang/rust#136889). My assumption is that this should be
carried over.
The test was carried over from rust-lang/rust#137193 which was superseded by rust-lang/rust#140035.
Thankfully, either way, `-Zunpretty` is unstable and we can always
change it even if we stabilize frontmatter.
Fix `--skip-std-check-if-no-download-rustc`
Since https://github.com/rust-lang/rust/pull/143048, we now explicitly set the build compiler for `check::Std`, which caused it to be built before we checked `--skip-std-check-if-no-download-rustc`. So I moved the check earlier to `make_run`, which resolves it.
I also added a regression test for this. Sadly we can't really test for the positive case easily (when download-ci-rustc is enabled), but we can test the negative cases, where it is disabled.
Fixes: https://github.com/rust-lang/rust/issues/143705
r? ```@RalfJung```
