Cleanup: Rid the `rmake` test runners of `extern crate run_make_support;`
`run_make_support` is part of the *extern prelude* of `rmake` test runners rendering `extern crate run_make_support` redundant:
80451a485b/src/tools/compiletest/src/runtest.rs (L3826-L3827)
~~Contains some fmt'ing changes because I've enabled format-on-save in my editor and because we don't run `x fmt` for `rmake` test runners yet (this gets addressed by #124613). I can revert those if you'd like me to.~~ (reverted)
r? jieyouxu or testing-devex(?) or boostrap(?)
Use an explicit x86-64 cpu in tests that are sensitive to it
There are a few tests that depend on some target features **not** being
enabled by default, and usually they are correct with the default x86-64
target CPU. However, in downstream builds we have modified the default
to fit our distros -- `x86-64-v2` in RHEL 9 and `x86-64-v3` in RHEL 10
-- and the latter especially trips tests that expect not to have AVX.
These cases are few enough that we can just set them back explicitly.
Adjust `#[macro_export]`/doctest help suggestion for non_local_defs lint
This PR adjust the help suggestion of the `non_local_definitions` lint when encountering a `#[macro_export]` at top-level doctest.
So instead of a non-sentential help suggestion to move the `macro_rules!` up above the `rustdoc`-generated function. We now suggest users to declare their own function.
Fixes *(partially, needs backport)* #124534
Add a lint against never type fallback affecting unsafe code
~~I'm not very happy with the code quality... `VecGraph` not allowing you to get predecessors is very annoying. This should work though, so there is that.~~ (ended up updating `VecGraph` to support getting predecessors)
~~First few commits are from https://github.com/rust-lang/rust/pull/123934https://github.com/rust-lang/rust/pull/123980~~
Rewrite select (in the new solver) to use a `ProofTreeVisitor`
We can use a proof tree visitor rather than collecting and recomputing all the nested goals ourselves.
Based on #124415
There are a few tests that depend on some target features **not** being
enabled by default, and usually they are correct with the default x86-64
target CPU. However, in downstream builds we have modified the default
to fit our distros -- `x86-64-v2` in RHEL 9 and `x86-64-v3` in RHEL 10
-- and the latter especially trips tests that expect not to have AVX.
These cases are few enough that we can just set them back explicitly.
Cleanup: Replace item names referencing GitHub issues or error codes with something more meaningful
**lcnr** in https://github.com/rust-lang/rust/pull/117164#pullrequestreview-1969935387:
> […] while I know that there's precendent to name things `Issue69420`, I really dislike this as it requires looking up the issue to figure out the purpose of such a variant. Actually referring to the underlying issue, e.g. `AliasMayNormToUncovered` or whatever and then linking to the issue in a doc comment feels a lot more desirable to me. We should ideally rename all the functions and enums which currently use issue numbers.
I've grepped through `compiler/` like crazy and think that I've found all instances of this pattern.
However, I haven't renamed `compute_2229_migrations_*`. Should I?
The first commit introduces an abhorrent and super long name for an item because naming is hard but also scary looking / unwelcoming names are good for things related to temporary-ish backcompat hacks. I'll let you discover it by yourself.
Contains a bit of drive-by cleanup and a diag migration bc that was the simplest option.
r? lcnr or compiler
Lazily normalize inside trait ref during orphan check & consider ty params in rigid alias types to be uncovered
Fixes#99554, fixesrust-lang/types-team#104.
Fixes#114061.
Supersedes #100555.
Tracking issue for the future compatibility lint: #124559.
r? lcnr
Add test for issue 106269
Closes#106269
Made this an assembly test as the LLVM codegen is still quite verbose and doesn't really indicate the behaviour we want
Port repr128-dwarf run-make test to rmake
This PR ports the repr128-dwarf run-make test to rmake, using the `gimli` crate instead of the `llvm-dwarfdump` command.
Note that this PR changes `rmake.rs` files to be compiled with the 2021 edition (previously no edition was passed to `rustc`, meaning they were compiled with the 2015 edition). This means that `panic!("{variable}")` will now work as expected in `rmake.rs` files (there's already a usage in the [wasm-symbols-not-exported test](aca749eefc/tests/run-make/wasm-symbols-not-exported/rmake.rs (L34)) that this will fix).
Tracking issue: #121876
Rollup of 4 pull requests
Successful merges:
- #124519 (adapt a codegen test for llvm 19)
- #124524 (Add StaticForeignItem and use it on ForeignItemKind)
- #124540 (Give proof tree visitors the ability to instantiate nested goals directly)
- #124543 (codegen tests: Tolerate `range()` qualifications in enum tests)
r? `@ghost`
`@rustbot` modify labels: rollup
codegen tests: Tolerate `range()` qualifications in enum tests
Current LLVM can infer range bounds on the i8s involved with these tests, and annotates it. Accept these bounds if present.
`@rustbot` label: +llvm-main
cc `@durin42`
Add StaticForeignItem and use it on ForeignItemKind
This is in preparation for unsafe extern blocks that adds a safe variant for functions inside extern blocks.
r? `@oli-obk`
cc `@compiler-errors`
coverage: Replace boolean options with a `CoverageLevel` enum
After #123409, and some discussion at https://github.com/rust-lang/rust/issues/79649#issuecomment-2042093553 and #124120, it became clear to me that we should have a unified concept of “coverage level”, instead of having several separate boolean flags that aren't actually independent.
This PR therefore introduces a `CoverageLevel` enum, to replace the existing boolean flags for `branch` and `mcdc`.
The `no-branch` value (for `-Zcoverage-options`) has been renamed to `block`, instructing the compiler to only instrument for block coverage, with no branch coverage or MD/DC instrumentation.
`@rustbot` label +A-code-coverage
cc `@ZhuUx` `@Lambdaris` `@RenjiSann`
Add a note to the ArbitraryExpressionInPattern error
The current "arbitrary expressions aren't allowed in patterns" error is confusing, as it fires for code where it *looks* like a pattern but the compiler still treats it as an expression. That this is due to the `:expr` fragment specifier forcing the expression-ness property on the code.
In the test suite, the "arbitrary expressions aren't allowed in patterns" error can only be found in combination with macro_rules macros that force expression-ness of their content, namely via `:expr` metavariables. I also can't come up with cases where there would be an expression instead of a pattern, so I think it's always coming from an `:expr`.
In order to make the error less confusing, this adds a note explaining the weird `:expr` fragment behaviour.
Fixes#99380
[Refactor] Rename `Lint` and `LintGroup`'s `is_loaded` to `is_externally_loaded`
The field being named `is_loaded` was very confusing. Turns out it's true for lints that are registered by external tools like Clippy (I had to look at https://github.com/rust-lang/rust/pull/116412 to know what the variable meant). So I renamed `is_loaded` to `is_externally_loaded` and added some docs.
Mark unions non-const-propagatable in `KnownPanicsLint` without calling layout
Fixes#123710
The ICE occurs during the layout calculation of the union `InvalidTag` in #123710 because the following assert fails:5fe8b697e7/compiler/rustc_abi/src/layout.rs (L289-L292)
The layout calculation is invoked by `KnownPanicsLint` when it is trying to figure out which locals it can const prop. Since `KnownPanicsLint` is never actually going to const props unions thanks to PR https://github.com/rust-lang/rust/pull/121628 there's no point calling layout to check if it can. So in this fix I skip the call to layout and just mark the local non-const propagatable if it is a union.
Fix#124478 - offset_of! returns a temporary
This was due to the must_use() call. Adding HIR's `OffsetOf` to the must_use checking within the compiler avoids this issue while maintaining the lint output.
Fixes#124478. `@tgross35`
MCDC coverage: support nested decision coverage
#123409 provided the initial MCDC coverage implementation.
As referenced in #124144, it does not currently support "nested" decisions, like the following example :
```rust
fn nested_if_in_condition(a: bool, b: bool, c: bool) {
if a && if b || c { true } else { false } {
say("yes");
} else {
say("no");
}
}
```
Note that there is an if-expression (`if b || c ...`) embedded inside a boolean expression in the decision of an outer if-expression.
This PR proposes a workaround for this cases, by introducing a Decision context stack, and by handing several `temporary condition bitmaps` instead of just one.
When instrumenting boolean expressions, if the current node is a leaf condition (i.e. not a `||`/`&&` logical operator nor a `!` not operator), we insert a new decision context, such that if there are more boolean expressions inside the condition, they are handled as separate expressions.
On the codegen LLVM side, we allocate as many `temp_cond_bitmap`s as necessary to handle the maximum encountered decision depth.
