| Age | Commit message (Collapse) | Author | Lines |
|---|
|
tests: Require `run-fail` ui tests to have an exit code (`SIGABRT` not ok)
And introduce two new directives for ui tests:
* `run-crash`
* `run-fail-or-crash`
Normally a `run-fail` ui test like tests that panic shall not be terminated by a signal like `SIGABRT`. So begin having that as a hard requirement.
Some of our current tests do terminate by a signal/crash however. Introduce and use `run-crash` for those tests. Note that Windows crashes are not handled by signals but by certain high bits set on the process exit code. Example exit code for crash on Windows: `0xc000001d` (`STATUS_ILLEGAL_INSTRUCTION`). Because of this, we define "crash" on all platforms as "not exit with success and not exit with a regular failure code in the range 1..=127".
Some tests behave differently on different targets:
* Targets without unwind support will abort (crash) instead of exit with failure code 101 after panicking. As a special case, allow crashes for `run-fail` tests for such targets.
* Different sanitizer implementations handle detected memory problems differently. Some abort (crash) the process while others exit with failure code 1. Introduce and use `run-fail-or-crash` for such tests.
This adds further (cc https://github.com/rust-lang/rust/pull/142304, https://github.com/rust-lang/rust/pull/142886) protection against the regression in https://github.com/rust-lang/rust/issues/123733 since that bug also manifested as `SIGABRT` in `tests/ui/panics/panic-main.rs` (shown as `Aborted (core dumped)` in the logs attached to that issue, and I have also been able to reproduce this locally).
### TODO
- [x] **Q:** what about on Windows?
**A:** we'll treat any exit code outside of 1 - 127 as "crashed", and we'll do the same on unix.
- [x] test all permutations of actual vs expected
**Done:** See https://github.com/rust-lang/rust/pull/143002#issuecomment-3007502894.
- [x] Handle targets without unwind support
- [x] Add `run-fail-or-crash` for some sanitizer tests
- [x] remote-test-client. See https://github.com/rust-lang/rust/pull/143448
### Zulip discussion
See https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/compiletest.3A.20terminate.20by.20signal.20vs.20exit.20with.20error/with/525611235
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
try-job: test-various
try-job: armhf-gnu
|
|
compiler & tools dependencies:
Locking 15 packages to latest compatible versions
Updating chrono-tz v0.10.3 -> v0.10.4
Removing chrono-tz-build v0.4.1
Updating clap v4.5.40 -> v4.5.41
Updating clap_builder v4.5.40 -> v4.5.41
Updating clap_derive v4.5.40 -> v4.5.41
Updating crc32fast v1.4.2 -> v1.5.0
Updating derive_setters v0.1.7 -> v0.1.8
Updating libredox v0.1.4 -> v0.1.6
Updating measureme v12.0.1 -> v12.0.3
Removing parse-zoneinfo v0.3.1
Adding phf v0.12.1
Adding phf_shared v0.12.1
Updating rustix v1.0.7 -> v1.0.8
Updating serde_json v1.0.140 -> v1.0.141
Updating sysinfo v0.36.0 -> v0.36.1
Updating wasi-preview1-component-adapter-provider v34.0.1 -> v34.0.2
Updating winnow v0.7.11 -> v0.7.12
note: pass `--verbose` to see 39 unchanged dependencies behind latest
library dependencies:
Locking 0 packages to latest compatible versions
note: pass `--verbose` to see 3 unchanged dependencies behind latest
rustbook dependencies:
Locking 13 packages to latest compatible versions
Updating ammonia v4.1.0 -> v4.1.1
Updating cc v1.2.29 -> v1.2.30
Updating clap v4.5.40 -> v4.5.41
Updating clap_builder v4.5.40 -> v4.5.41
Updating clap_complete v4.5.54 -> v4.5.55
Updating clap_derive v4.5.40 -> v4.5.41
Updating crc32fast v1.4.2 -> v1.5.0
Updating html5ever v0.31.0 -> v0.35.0
Updating markup5ever v0.16.2 -> v0.35.0
Updating match_token v0.1.0 -> v0.35.0
Updating rustix v1.0.7 -> v1.0.8
Updating serde_json v1.0.140 -> v1.0.141
Updating winnow v0.7.11 -> v0.7.12
|
|
It used to search for `'foo` which won't find `'r#foo`, now we search for `foo` instead.
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#143960 (Tidy cleanup 2)
- rust-lang/rust#144149 (docs: update link to RISC-V and Xtensa installation guide)
- rust-lang/rust#144152 (Rename `optional-mingw-check-1` to `optional-pr-check-1`)
- rust-lang/rust#144178 (Fix clippy lints in librustdoc)
- rust-lang/rust#144180 (fix load-bearing typo)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
intrinsics
|
|
|
|
|
|
|
|
|
|
Prepare revert of 144013
This is a possible revert for rust-lang/rust#144013 causing issue rust-lang/rust#144168 (imo p-crit) to give us time to figure out a correct fix for rust-lang/rust#144013 without pressure. Feel free to close if it's an easy fix instead: r? `@petrochenkov`
|
|
And introduce two new directives for ui tests:
* `run-crash`
* `run-fail-or-crash`
Normally a `run-fail` ui test like tests that panic shall not be
terminated by a signal like `SIGABRT`. So begin having that as a hard
requirement.
Some of our current tests do terminate by a signal/crash however.
Introduce and use `run-crash` for those tests. Note that Windows crashes
are not handled by signals but by certain high bits set on the process
exit code. Example exit code for crash on Windows: `0xc000001d`.
Because of this, we define "crash" on all platforms as "not exit with
success and not exit with a regular failure code in the range 1..=127".
Some tests behave differently on different targets:
* Targets without unwind support will abort (crash) instead of exit with
failure code 101 after panicking. As a special case, allow crashes for
`run-fail` tests for such targets.
* Different sanitizer implementations handle detected memory problems
differently. Some abort (crash) the process while others exit with
failure code 1. Introduce and use `run-fail-or-crash` for such tests.
|
|
fix load-bearing typo
Trying to see if this is enough to fix PR CI. How did it land without issues is a question for later.
<sub>I can see the headlines already, "billion dollar infrastructure brought down by load-bearing typo".</sub>
|
|
Fix clippy lints in librustdoc
|
|
Rename `optional-mingw-check-1` to `optional-pr-check-1`
I noticed this when doing a `bors2 try` for `mingw`.
I also changed it to use the `pr-check-1` image as `mingw-check-1` no longer exists.
|
|
docs: update link to RISC-V and Xtensa installation guide
Replace outdated link https://docs.esp-rs.org/book/installation/riscv-and-xtensa.html with the official Espressif documentation at https://docs.espressif.com/projects/rust/book/installation/index.html
|
|
Tidy cleanup 2
|
|
|
|
|
|
Add `ToolTarget` to bootstrap
Oh, you thought I'm done with refactoring bootstrap tools? Na-ah, think again! After the failure of https://github.com/rust-lang/rust/pull/143581, `ToolTarget` is back with a vengeance. This time, I implemented the test changes and tool cleanups without forcing these tools to be built with the stage0 compiler.
There are still some small wins though, `LlvmBitcodeLinker` now starts at stage 1, and not stage 2. Cargo should also be ported to this new mode, but I'm leaving that for a follow-up PR.
Hopefully X-th time's the charm :crossed_fingers:
r? `@jieyouxu`
|
|
update dependencies
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#141076 (fix Zip unsoundness (again))
- rust-lang/rust#142444 (adding run-make test to autodiff)
- rust-lang/rust#143704 (Be a bit more careful around exotic cycles in in the inliner)
- rust-lang/rust#144073 (Don't test panic=unwind in panic_main.rs on Fuchsia)
- rust-lang/rust#144083 (miri sleep tests: increase slack)
- rust-lang/rust#144092 (bootstrap: Detect musl hosts)
- rust-lang/rust#144098 (Do not lint private-in-public for RPITIT)
- rust-lang/rust#144103 (Rename `emit_unless` to `emit_unless_delay`)
- rust-lang/rust#144108 (Ignore tests/run-make/link-eh-frame-terminator/rmake.rs when cross-compiling)
- rust-lang/rust#144115 (fix outdated comment)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
add -Zmiri-no-extra-rounding-error to specifically disable just that part of float-nondet
|
|
float-nondet
|
|
This reverts commit 998df3a3e851908afd05c3318f16d99849af5c55.
|
|
minor: remove unused var
|
|
|
|
|
|
|
|
Simplify discriminant codegen for niche-encoded variants which don't wrap across an integer boundary
Inspired by rust-lang/rust#139729, this attempts to be a much-simpler and more-localized change while still making a difference. (Specifically, this does not try to solve the problem with select-sinking, leaving that to be fixed by https://github.com/llvm/llvm-project/issues/134024 -- once it gets released -- instead of in rustc's codegen.)
What this *does* improve is checking for the variant in a 3+ variant enum when that variant is the type providing the niche. Something like `if let Foo::WithBool(_) = ...` previously compiled to `ugt(add(x, -2), 2)`, which is non-trivial to think about because it's depending on the unsigned wrapping to shift the 0/1 up above 2. With this PR it compiles to just `ult(x, 2)`, which is probably what you'd have written yourself if you were doing it by hand to look for "is this byte a bool?".
That's done by leaving most of the codegen alone, but adding a couple new special cases to the `is_niche` check. The default looks at the relative discriminant, but in the common cases where there's no wraparound involved, we can just check the original value, rather than the offsetted one.
The first commit just adds some tests, so the best way to see the effect of this change is to look at the second commit and how it updates the test expectations.
|
|
Automatic Rustup
|
|
|
|
fix outdated comment
cc rust-lang/rust#84857
r? types
|
|
Ignore tests/run-make/link-eh-frame-terminator/rmake.rs when cross-compiling
The test tests/run-make/link-eh-frame-terminator/rmake.rs fails to link when cross-compiling. Therefore, it should be ignored in cross-compilation environments.
See [commit a27bdea](https://github.com/rust-lang/rust/commit/a27bdea4b7b5107ea912659813418445d9e46ba4) and [commit 2beccc4](https://github.com/rust-lang/rust/commit/2beccc4d8e5066a42e6623d91e7991870d36feb2) for reference.
|
|
Rename `emit_unless` to `emit_unless_delay`
`emit_unless` is very unintuitive and confusing. The first impression is as if it will only emit if the parameter is true, without the altnative "delay as a bug".
`emit_unless_delay` expresses two things:
1. emit unless the `delay` parameter is true
2. either *emit immediately* or *delay as bug*
r? `@compiler-errors`
|
|
Do not lint private-in-public for RPITIT
Fixes the hard error introduced by https://github.com/rust-lang/rust/pull/143357
Instead of trying to accept this hard error directly, this PR copies tests from https://github.com/rust-lang/rust/pull/144020 and removes the error.
If the behaviour is actually desirable, the second commit can be reverted with a proper crater run.
cc https://github.com/rust-lang/rust/issues/143531 for bookkeeping
r? `@compiler-errors`
|
|
bootstrap: Detect musl hosts
Currently, all non-Android Linux hosts are assumed to be using glibc. This obviously isn't very portable and will currently result in downloading a stage0 toolchain for glibc even on musl hosts.
There are multiple ways to detect musl somewhat reliably, but the easiest option is to check for the python target, which is exposed in `sys.implementation._multiarch` and has values like "x86_64-linux-gnu" or "powerpc64le-linux-musl".
|
|
miri sleep tests: increase slack
Filing this directly as a rustc PR since it impacts rustc CI (see https://github.com/rust-lang/rust/pull/144075#issuecomment-3085293055)
r? `````@oli-obk`````
|
|
Don't test panic=unwind in panic_main.rs on Fuchsia
````@Enselic```` added a few new test conditions to tests/ui/panics/panic-main.rs in rust-lang/rust#142304, but it is unfortunately causing the test to fail for Fuchsia with the `panic=unwind` modes since we compile Rust for Fuchsia with `panic=abort`. This patch just ignores the test for Fuchsia.
Note that this test might also need to filter out a few other platforms, since another panicking test we exclude from Fuchsia https://github.com/rust-lang/rust/blob/master/tests/ui/panics/runtime-switch.rs also excludes running on msvc, android, openbsd, and wasm, but I'm not familiar with those platforms so I didn't want to add them here.
cc ````@compile-errors,```` who reviewed the initial PR
|
|
Be a bit more careful around exotic cycles in in the inliner
Copied from the comment here: https://github.com/rust-lang/rust/issues/143700#issuecomment-3053810353
---
```rust
#![feature(fn_traits)]
#[inline]
pub fn a() {
FnOnce::call_once(a, ());
FnOnce::call_once(b, ());
}
#[inline]
pub fn b() {
FnOnce::call_once(b, ());
FnOnce::call_once(a, ());
}
```
This should demonstrate the issue. For ease of discussion, I'm gonna call the two fn-def types `{a}` and `{b}`.
When collecting the cyclic local callees in `mir_callgraph_cyclic` for `a`, we first check the first call terminator in `a`. We end up calling process on `<{a} as FnOnce>::call_once`, which ends up visiting `a`'s instance again. This is cyclical. However, we don't end up marking `FnOnce::call_once` as a cyclical def id because it's a foreign item. That's fine.
When visiting the second call terminator in `a`, which is `<{b} as FnOnce>::call_once`, we end up recursing into `b`. We check the first terminator, which is `<{b} as FnOnce>::call_once`, but although that is its own mini cycle, it doesn't consider itself a cycle for the purpose of this query because it doesn't involve the *root*. However, when we visit the *second* terminator in `b`, which is `<{a} as FnOnce>::call_once`, we end up **erroneously** *not* considering that call to be cyclical since we've already inserted it into our set of seen instances, and as a consequence we don't recurse into it. This means that we never collect `b` as recursive.
Do this in the flipped case too, and we end up having two functions which mututally do not consider each other to be recursive participants. This leads to a query cycle.
---
I ended up also renaming some variables so I could more clearly understand their responsibilities in this code. Let me know if the renames are not welcome.
Fixes https://github.com/rust-lang/rust/issues/143700
r? `@cjgillot`
|
