Add more `begin_panic` normalizations to panic backtrace tests
Since #123244, these tests have started failing locally on some systems (#133997) due to minor variations in how `begin_panic` is printed in the backtrace.
The variation appears to occur on macOS when `rust.debuginfo-level = "line-tables-only"` is set, which is the default in `config.compiler.toml`. It does not occur when the debuginfo level is set to 1.
The variation doesn't seem relevant to these tests, so this PR simply adds another custom normalization rule to account for the variation.
---
Will conflict with #134759.
Migrate `incr-add-rust-src-component` to rmake
This PR partially supersedes #128562, and ports the Makefile-based `tests/run-make/incr-add-rust-src-component` to use rmake.rs infra.
Part of #121876.
This run-make test is a regression test for https://github.com/rust-lang/rust/issues/70924. It (tries to) checks that if we add the `rust-src` component in between two incremental compiles, that the compiler doesn't ICE on the second invocation.
- Original issue:https://github.com/rust-lang/rust/issues/70924
- Fix PR: https://github.com/rust-lang/rust/pull/72767
- PR adding this regression test: https://github.com/rust-lang/rust/pull/72952
However, the Makefile version of this used `$SYSROOT/lib/rustlib/src/rust/src/libstd/lib.rs`, but that actually got moved around and reorganized over the years. As of Dec 2024, the `rust-src` component is more like (specific for our purposes):
```
$SYSROOT/lib/rustlib/src/rust/
library/std/src/lib.rs
src/
```
However, this run-make test is ancient and it exercises incr-comp system logic. I'm not sure if this test would actually catch the original regression.
This PR was co-authored with `@Oneirical.`
r? incremental
try-job: i686-msvc
try-job: x86_64-mingw-1
try-job: x86_64-msvc
try-job: aarch64-apple
fix default-backtrace-ice test
when running `tests/ui/panics/default-backtrace-ice.rs locally it gave this error:
```
failures:
---- [ui] tests/ui/panics/default-backtrace-ice.rs stdout ----
Saved the actual stderr to "/home/jyn/src/rust3/build/x86_64-unknown-linux-gnu/test/ui/panics/default-backtrace-ice/default-backtrace-ice.stderr"
diff of stderr:
7
8 aborting due to `-Z treat-err-as-bug=1`
9 stack backtrace:
- (end_short_backtrace)
- (begin_short_backtrace)
- (end_short_backtrace)
- (begin_short_backtrace)
+ [... omitted 22 frames ...]
+
```
(note that you must *not* use --bless; we previously did not have an error annotation to verify it was a full backtrace instead of a short backtrace.)
this is a regression from setting RUST_BACKTRACE=1 by default in https://github.com/rust-lang/rust/pull/134743. we need to turn off the new behavior when running UI tests so that they reflect our dist compiler. normally that's done by checking `sess.unstable_opts.ui_testing`, but this happens extremely early in the compiler before we've expanded arg files. do an extremely simple hack that doesn't work in all cases - we don't need it to work in all cases, only when running UI tests.
cc https://github.com/rust-lang/rust/pull/129658#issuecomment-2561988081
r? `@jieyouxu`
when running `tests/ui/panics/default-backtrace-ice.rs locally it gave this error:
```
failures:
---- [ui] tests/ui/panics/default-backtrace-ice.rs stdout ----
Saved the actual stderr to "/home/jyn/src/rust3/build/x86_64-unknown-linux-gnu/test/ui/panics/default-backtrace-ice/default-backtrace-ice.stderr"
diff of stderr:
7
8 aborting due to `-Z treat-err-as-bug=1`
9 stack backtrace:
- (end_short_backtrace)
- (begin_short_backtrace)
- (end_short_backtrace)
- (begin_short_backtrace)
+ [... omitted 22 frames ...]
+
```
this is a regression from setting RUST_BACKTRACE=1 by default. we need to turn off the new behavior when running UI tests so that they reflect our dist compiler. normally that's done by checking `sess.unstable_opts.ui_testing`, but this happens extremely early in the compiler before we've expanded arg files. do an extremely simple hack that doesn't work in all cases - we don't need it to work in all cases, only when running UI tests.
Detect when a manual `Default` implementation isn't using the existing default field values and suggest using `..` instead:
```
error: `Default` impl doesn't use the declared default field values
--> $DIR/manual-default-impl-could-be-derived.rs:14:1
|
LL | / impl Default for A {
LL | | fn default() -> Self {
LL | | A {
LL | | y: 0,
| | - this field has a default value
... |
LL | | }
| |_^
|
= help: use the default values in the `impl` with `Struct { mandatory_field, .. }` to avoid them diverging over time
note: the lint level is defined here
--> $DIR/manual-default-impl-could-be-derived.rs:5:9
|
LL | #![deny(default_overrides_default_fields)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Run `tests/ui/backtrace/std-backtrace.rs` on MSVC.
The original PR which disabled these, https://github.com/rust-lang/rust/pull/62897, only mentions them being broken on i686. ~~let's still make sure the rest of windows is supported.~~ Let's see if we can enable this for msvc now (32-bit and 64-bit).
r? `@jieyouxu`
try-job: x86_64-msvc
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-mingw-1
try-job: x86_64-mingw-2
try-job: dist-x86_64-msvc
try-job: dist-i686-msvc
The original PR which disabled these only mentions them being broken on
i686 msvc. Let's try to see if we can reenable this test for msvc (both
32-bit and 64-bit).
Update `#[coverage(..)]` attribute error messages to match the current implementation
The allowed positions for `#[coverage(..)]` attributes were expanded by #126721, but the corresponding error messages were never updated to reflect the new behaviour.
Part of #134749.
Consider arm to diverge if guard diverges
This is not a fix for #134734, but I discovered it when I was gauging how difficult it would be to fix that. It does fix a really old test though :>
r? `@WaffleLapkin` or reassign
Correctly note item kind in `NonConstFunctionCall` error message
Don't just call everything a "`fn`". This is more consistent with the error message we give for conditionally-const items, which do note the item's def kind.
r? fmease, this is a prerequisite for making those `~const PartialEq` error messages better. Re-roll if you're busy or don't want to review this.
core: fix const ptr::swap_nonoverlapping when there are pointers at odd offsets
Ensure that the pointer gets swapped correctly even if it is not stored at an aligned offset. This rules out implementations that copy things in a `usize` loop -- so our implementation needs to be adjusted to avoid such a loop when running in const context.
Part of https://github.com/rust-lang/rust/issues/133668
Begin to implement type system layer of unsafe binders
Mostly TODOs, but there's a lot of match arms that are basically just noops so I wanted to split these out before I put up the MIR lowering/projection part of this logic.
r? oli-obk
Tracking:
- https://github.com/rust-lang/rust/issues/130516
Clean up a few rmake tests
Now I'm aware it's a bit late to start participating in the Advent of Tests, but here are a few cleanups in the rmake tests to put under the 🎄 anyways. A handful of unused imports, some warnings, and a couple typos.
r? `@jieyouxu` 🎅
opt-dist: propagate channel info to bootstrap
Fixes#133503.
Previously, `tests/ui/bootstrap/rustc_bootstap.rs` [sic] failed during [beta bump](https://github.com/rust-lang/rust/pull/133447#issuecomment-2501298794) in opt-dist tests. This is because:
- `opt-dist` tried to run `./x test` against beta-channel dist `rustc` through `bootstrap`.
- The dist build produced during the beta bump produces a `rustc` which correctly thinks that it is a beta compiler based on `src/ci/channel` info.
- `opt-dist` tries to run `./x test` on the beta `rustc` from the dist build, but without specifying channel through a synthetic `config.toml`, so `bootstrap` tells `compiletest` that we're on the `nightly` channel (by default).
- Now there's a channel mismatch: `compiletest` believes the `rustc` under test is a *nightly* rustc, but the `rustc` under test actually considers itself a *beta* rustc. This means that `//@ only-nightly` will be satisfied yet the test will fail as the *beta* rustc is not a *nightly* rustc.
This PR:
- Fixes the test failure during beta bump (i.e. #133503) by having `opt-dist` faithfully report the channel of the dist `rustc` being tested (i.e. "beta" in a beta bump PR). This will properly make the test be ignored during beta bump as the `rustc` under test is not a *nightly* rustc.
- Fixes the test name `rustc_bootstap.rs` -> `rustc_bootstrap.rs`. No more stapping.
- Slightly adjusts the doc comment in the test to make it more clear.
I ran a try-job against the beta branch (explicitly running the opt-dist tests by modifying the job definition) with these changes in #134131, and it appears that the try-job was [successful](https://github.com/rust-lang/rust/pull/134131#issuecomment-2555492215). The two commits in this PR are cherry-picked from #134131, with the test commit slightly modified (to also adjust the test comments).
r? `@Kobzol` (or compiler or bootstrap or infra I guess?)
The Makefile version seems to contain a bug. Over the years, the
directory structure of the `rust-src` component changed as the source
tree directory structure changed. `libstd` is no longer a thing directly
under `root/lib/rustlib/src/rust/src/`, it is moved to
`root/lib/rustlib/src/rust/library/std`.
Co-authored-by: Oneirical <manchot@videotron.ca>
