| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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`
|
|
adding run-make test to autodiff
r? `@ZuseZ4`
|
|
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. #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.
fixes #137255
|
|
This is blocking rust-lang/rust-clippy#14724
changelog: none
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#138554 (Distinguish delim kind to decide whether to emit unexpected closing delimiter)
- rust-lang/rust#142673 (Show the offset, length and memory of uninit read errors)
- rust-lang/rust#142693 (More robustly deal with relaxed bounds and improve their diagnostics)
- rust-lang/rust#143382 (stabilize `const_slice_reverse`)
- rust-lang/rust#143928 (opt-dist: make llvm builds optional)
- rust-lang/rust#143961 (Correct which exploit mitigations are enabled by default)
- rust-lang/rust#144050 (Fix encoding of link_section and no_mangle cross crate)
- rust-lang/rust#144059 (Refactor `CrateLoader` into the `CStore`)
- rust-lang/rust#144123 (Generalize `unsize` and `unsize_into` destinations)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
so that we get more parallelism out of cargo
|
|
|
|
|
|
|
|
|
|
|
|
|
|
code generation
|
|
|
|
|
|
r=GuillaumeGomez
Subtree update cg gcc 2025 07 18
cc `@antoyo`
r? ghost
|
|
`intrinsic-test`: combine C files for faster compilation
|
|
|
|
|
|
`stdarch-test`: various cleanups
|
|
|
|
This makes `const` contexts use the `const`-stability version
information instead of the regular stability one, as `const`-stability
may happen much later than stability in non-`const` contexts.
~~It includes the content of PR rust-lang/rust-clippy#15296 as its first
commit. I separated them because this one is more complex, and
rust-lang/rust-clippy#15296 may be merged more rapidly.~~
changelog: [`incompatible_msrv`]: check the right MSRV when in a `const`
context
r? Jarcho @rustbot label +C-bug +I-false-negative
|
|
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: 82310651b93a594a3fd69015e1562186a080d94c
Filtered ref: e13c0be8f13737c64082b89ce834546079767ac4
This merge was created using https://github.com/rust-lang/josh-sync.
|
|
This updates the rust-version file to 82310651b93a594a3fd69015e1562186a080d94c.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
aaa
|
|
|
