-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Rollup of 10 pull requests #144166
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
Rollup of 10 pull requests #144166
Conversation
Some history: The Zip TrustedRandomAccess specialization has tried to emulate the side-effects of the naive implementation for a long time, including backwards iteration. 82292¹ tried to fix unsoundness (82291¹) in that side-effect-preservation code, but this introduced some panic-safety unsoundness (86443¹), but the fix 86452¹ didn't fix it for nested Zip iterators (137255¹). Rather than piling yet another fix ontop of this heap of fixes this PR reduces the number of cases in which side-effects will be preserved; the necessary API guarantee change was approved in 83791¹ but we haven't made use of that so far. ¹ see merge commit for linkfied issues.
Signed-off-by: Karan Janthe <karanjanthe@gmail.com>
Signed-off-by: Karan Janthe <karanjanthe@gmail.com>
Only run the panic=unwind tests on platforms that support unwinding.
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 SOABI config variable, which has values like "cpython-313-x86_64-linux-gnu" or "cpython-313-powerpc64-linux-musl". Signed-off-by: Jens Reidel <adrian@travitia.xyz>
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
…orkingjubilee fix Zip unsoundness (again) Some history: The Zip TrustedRandomAccess specialization has tried to emulate the side-effects of the naive implementation for a long time, including backwards iteration. rust-lang#82292 tried to fix unsoundness (rust-lang#82291) in that side-effect-preservation code, but this introduced some panic-safety unsoundness (rust-lang#86443), but the fix rust-lang#86452 didn't fix it for nested Zip iterators (rust-lang#137255). Rather than piling yet another fix ontop of this heap of fixes this PR reduces the number of cases in which side-effects will be preserved; the necessary API guarantee change was approved in rust-lang#83791 but we haven't made use of that so far. fixes rust-lang#137255
…useZ4 adding run-make test to autodiff r? `@ZuseZ4`
…gillot Be a bit more careful around exotic cycles in in the inliner Copied from the comment here: rust-lang#143700 (comment) --- ```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 rust-lang#143700 r? `@cjgillot`
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#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
miri sleep tests: increase slack Filing this directly as a rustc PR since it impacts rustc CI (see rust-lang#144075 (comment)) r? `````@oli-obk`````
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".
…rrors Do not lint private-in-public for RPITIT Fixes the hard error introduced by rust-lang#143357 Instead of trying to accept this hard error directly, this PR copies tests from rust-lang#144020 and removes the error. If the behaviour is actually desirable, the second commit can be reverted with a proper crater run. cc rust-lang#143531 for bookkeeping r? `@compiler-errors`
…rrors 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`
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](rust-lang@a27bdea) and [commit 2beccc4](rust-lang@2beccc4) for reference.
…r-errors fix outdated comment cc rust-lang#84857 r? types
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 83825dd277 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 83825dd (parent) -> 12865ff (this PR) Test differencesShow 77 test diffsStage 1
Stage 2
Additionally, 5 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 12865ffd0dfb4ea969e2f16eb0140238bb9dd382 --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Finished benchmarking commit (12865ff): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 1.9%, secondary -1.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeResults (primary -0.2%, secondary -0.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 465.281s -> 465.616s (0.07%) |
Successful merges:
emit_unless
toemit_unless_delay
#144103 (Renameemit_unless
toemit_unless_delay
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup