rustc pull #2228
Merged
rustc pull #2228
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…able_modules to more items
Outline panicking code for `LocalKey::with` See rust-lang/rust#115491 for prior related modifications. https://godbolt.org/z/MTsz87jGj shows a reduction of the code size for TLS accesses.
CI: split x86_64-msvc job using windows 2025 try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: dist-x86_64-msvc
Rework dyn trait lowering to stop being so intertwined with trait alias expansion This PR reworks the trait object lowering code to stop handling trait aliases so funky, and removes the `TraitAliasExpander` in favor of a much simpler design. This refactoring is important for making the code that I'm writing in rust-lang/rust#133397 understandable and easy to maintain, so the diagnostics regressions are IMO inevitable. In the old trait object lowering code, we used to be a bit sloppy with the lists of traits in their unexpanded and expanded forms. This PR largely rewrites this logic to expand the trait aliases *once* and handle them more responsibly throughout afterwards. Please review this with whitespace disabled. r? lcnr
remove support for the (unstable) #[start] attribute As explained by `@Noratrieb:` `#[start]` should be deleted. It's nothing but an accidentally leaked implementation detail that's a not very useful mix between "portable" entrypoint logic and bad abstraction. I think the way the stable user-facing entrypoint should work (and works today on stable) is pretty simple: - `std`-using cross-platform programs should use `fn main()`. the compiler, together with `std`, will then ensure that code ends up at `main` (by having a platform-specific entrypoint that gets directed through `lang_start` in `std` to `main` - but that's just an implementation detail) - `no_std` platform-specific programs should use `#![no_main]` and define their own platform-specific entrypoint symbol with `#[no_mangle]`, like `main`, `_start`, `WinMain` or `my_embedded_platform_wants_to_start_here`. most of them only support a single platform anyways, and need cfg for the different platform's ways of passing arguments or other things *anyways* `#[start]` is in a super weird position of being neither of those two. It tries to pretend that it's cross-platform, but its signature is a total lie. Those arguments are just stubbed out to zero on ~~Windows~~ wasm, for example. It also only handles the platform-specific entrypoints for a few platforms that are supported by `std`, like Windows or Unix-likes. `my_embedded_platform_wants_to_start_here` can't use it, and neither could a libc-less Linux program. So we have an attribute that only works in some cases anyways, that has a signature that's a total lie (and a signature that, as I might want to add, has changed recently, and that I definitely would not be comfortable giving *any* stability guarantees on), and where there's a pretty easy way to get things working without it in the first place. Note that this feature has **not** been RFCed in the first place. *This comment was posted [in May](rust-lang/rust#29633 (comment)) and so far nobody spoke up in that issue with a usecase that would require keeping the attribute.* Closes rust-lang/rust#29633 try-job: x86_64-gnu-nopt try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: test-various
Update our range `assume`s to the format that LLVM prefers I found out in llvm/llvm-project#123278 (comment) that the way I started emitting the `assume`s in #109993 was suboptimal, and as seen in that LLVM issue the way we're doing it -- with two `assume`s sometimes -- can at times lead to CVP/SCCP not realize what's happening because one of them turns into a `ne` instead of conveying a range. So this updates how it's emitted from ``` assume( x >= LOW ); assume( x <= HIGH ); ``` or ``` // (for ranges that wrap the range) assume( (x <= LOW) | (x >= HIGH) ); ``` to ``` assume( (x - LOW) <= (HIGH - LOW) ); ``` so that we don't need multiple `icmp`s nor multiple `assume`s for a single value, and both wrappping and non-wrapping ranges emit the same shape. (And we don't bother emitting the subtraction if `LOW` is zero, since that's trivial for us to check too.)
Add test for checking used glibc symbols This test checks that we do not use too new glibc symbols in the compiler on x64 GNU Linux, in order not to break our [glibc promises](https://blog.rust-lang.org/2022/08/01/Increasing-glibc-kernel-requirements.html). One thing that isn't solved in the PR yet is to make sure that this test will only run on `dist` CI, more specifically on the `dist-x86_64-linux` runner, in the opt-dist post-optimization tests (it can fail elsewhere, that doesn't matter). Any suggestions on how to do that are welcome. Fixes: rust-lang/rust#134037 r? `@jieyouxu`
tests: Port `jobserver-error` to rmake.rs Part of #121876. This PR ports `tests/run-make/jobserver-error` to rmake.rs, and is basically #128789 slightly adjusted. The complexity involved here is mostly how to get `/dev/null/` piping to fd 3 working with std `Command`, whereas with a shell this is much easier (as is evident with the `Makefile` version). Supersedes #128789. This PR is co-authored with `@Oneirical` and `@coolreader18.` try-job: aarch64-gnu try-job: i686-gnu-1 try-job: x86_64-gnu-debug try-job: x86_64-gnu-llvm-18-1
Automatic Rustup
Refactor `fmt::Display` impls in rustdoc This PR does a couple of things, with the intention of cleaning up and streamlining some of the `fmt::Display` impls in rustdoc: 1. Use the unstable [`fmt::from_fn`](rust-lang/rust#117729) instead of open-coding it. 2. ~~Replace bespoke implementations of `Itertools::format` with the method itself.~~ 4. Some more minor cleanups - DRY, remove unnecessary calls to `Symbol::as_str()`, replace some `format!()` calls with lazier options The changes are mostly cosmetic but some of them might have a slight positive effect on performance.
They can both be set inside the config callback too.
It has become nothing other than a wrapper around run_compiler.
Implement `ByteStr` and `ByteString` types Approved ACP: rust-lang/libs-team#502 Tracking issue: rust-lang/rust#134915 These types represent human-readable strings that are conventionally, but not always, UTF-8. The `Debug` impl prints non-UTF-8 bytes using escape sequences, and the `Display` impl uses the Unicode replacement character. This is a minimal implementation of these types and associated trait impls. It does not add any helper methods to other types such as `[u8]` or `Vec<u8>`. I've omitted a few implementations of `AsRef`, `AsMut`, and `Borrow`, when those would be the second implementation for a type (counting the `T` impl), to avoid potential inference failures. We can attempt to add more impls later in standalone commits, and run them through crater. In addition to the `bstr` feature, I've added a `bstr_internals` feature for APIs provided by `core` for use by `alloc` but not currently intended for stabilization. This API and its implementation are based *heavily* on the `bstr` crate by Andrew Gallant (`@BurntSushi).` r? `@BurntSushi`
…piler-errors
Add missing check for async body when suggesting await on futures.
Currently the compiler suggests adding `.await` to resolve some type conflicts without checking if the conflict happens in an async context. This can lead to the compiler suggesting `.await` in function signatures where it is invalid. Example:
```rs
trait A {
fn a() -> impl Future<Output = ()>;
}
struct B;
impl A for B {
fn a() -> impl Future<Output = impl Future<Output = ()>> {
async { async { () } }
}
}
```
```
error[E0271]: expected `impl Future<Output = impl Future<Output = ()>>` to be a future that resolves to `()`, but it resolves to `impl Future<Output = ()>`
--> bug.rs:6:15
|
6 | fn a() -> impl Future<Output = impl Future<Output = ()>> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found future
|
note: calling an async function returns a future
--> bug.rs:6:15
|
6 | fn a() -> impl Future<Output = impl Future<Output = ()>> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: required by a bound in `A::{synthetic#0}`
--> bug.rs:2:27
|
2 | fn a() -> impl Future<Output = ()>;
| ^^^^^^^^^^^ required by this bound in `A::{synthetic#0}`
help: consider `await`ing on the `Future`
|
6 | fn a() -> impl Future<Output = impl Future<Output = ()>>.await {
| ++++++
```
The documentation of suggest_await_on_expect_found (`compiler/rustc_trait_selection/src/error_reporting/infer/suggest.rs:156`) even mentions such a check but does not actually implement it.
This PR adds that check to ensure `.await` is only suggested within async blocks.
There were 3 unit tests whose expected output needed to be changed because they had the suggestion outside of async. One of them (`tests/ui/async-await/dont-suggest-missing-await.rs`) actually tests that exact problem but expects it to be present.
Thanks to `@llenck` for initially noticing the bug and helping with fixing it
handle global trait bounds defining assoc types This also fixes the compare-mode for - tests/ui/coherence/coherent-due-to-fulfill.rs - tests/ui/codegen/mono-impossible-2.rs - tests/ui/trivial-bounds/trivial-bounds-inconsistent-projection.rs - tests/ui/nll/issue-61320-normalize.rs I first considered the alternative to always prefer where-bounds during normalization, regardless of how the trait goal has been proven by changing `fn merge_candidates` instead. https://github.com/rust-lang/rust/blob/ecda83b30f0f68cf5692855dddc0bc38ee8863fc/compiler/rustc_next_trait_solver/src/solve/assembly/mod.rs#L785 This approach is more restrictive than behavior of the old solver to avoid mismatches between trait and normalization goals. This may be breaking in case the where-bound adds unnecessary region constraints and we currently don't ever try to normalize an associated type. I would like to detect these cases and change the approach to exactly match the old solver if required. I want to minimize cases where attempting to normalize in more places causes code to break. r? `@compiler-errors`
Get rid of RunCompiler The various `set_*` methods that have been removed can be replaced by setting the respective fields in the `Callbacks::config` implementation. `set_using_internal_features` was often forgotten and it's equivalent is now done automatically.
…piler-errors rustc_codegen_llvm: remove outdated asm-to-obj codegen note Remove comment about missing integrated assembler handling, which was removed in commit 02840ca.
Allow `arena_cache` queries to return `Option<&'tcx T>` Currently, `arena_cache` queries always have to return `&'tcx T`[^deref]. This means that if an arena-cached query wants to return an optional value, it has to return `&'tcx Option<T>`, which has a few negative consequences: - It goes against normal Rust style, where `Option<&T>` is preferred over `&Option<T>`. - Callers that actually want an `Option<&T>` have to manually call `.as_ref()` on the query result. - When the query result is `None`, a full-sized `Option<T>` still needs to be stored in the arena. This PR solves that problem by introducing a helper trait `ArenaCached` that is implemented for both `&T` and `Option<&T>`, and takes care of bridging between the provided type, the arena-allocated type, and the declared query return type. --- To demonstrate that this works, I have converted the two existing arena-cached queries that currently return `&Option<T>`: `mir_coroutine_witnesses` and `diagnostic_hir_wf_check`. Only the query declarations need to be modified; existing providers and callers continue to work with the new query return type. (My real goal is to apply this to `coverage_ids_info`, which will return Option as of #135873, but that PR hasn't landed yet.) [^deref]: Technically they could return other types that implement `Deref`, but it's hard to imagine this working well with anything other than `&T`.
simplify parse_format::Parser::ws by using next_if
Enable `unreachable_pub` lint in `test` and `proc_macro` crates This PR enables the [`unreachable_pub`](https://doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unreachable-pub) lint as warn in the `test` and `proc_macro` crates. The diff was mostly generated with `./x.py fix --stage 1 library/proc_macro/ -- --broken-code`, as well as manual edits for code in macros and in tests. Continuation of #134286 r? libs
Make it possible to build GCC on CI This is the first step towards eventually enabling download of precompiled GCC from our CI. Currently, we prebuild `libgccjit` on CI and cache it in Docker. This PR improves the bootstrap GCC step to make it work on CI, and also to make it faster by using sccache. After this change, an actual build on CI should take only 2-3 minutes. Note that this PR does not yet remove the `build-gccjit.sh` script and replace it with the bootstrap step, I'll leave that to a follow-up PR. The added `flex` package and the ZSTD library fix were needed to make GCC build on CI. CC ``````@GuillaumeGomez`````` r? ``````@onur-ozkan``````
support wasm inline assembly in `naked_asm!` fixes rust-lang/rust#135518 Webassembly was overlooked previously, but now `naked_asm!` and `#[naked]` functions work on the webassembly targets. Or, they almost do right now. I guess this is no surprise, but the `wasm32-unknown-unknown` target causes me some trouble. I'll add some inline comments with more details. r? ```````@bjorn3``````` cc ```````@daxpedda,``````` ```````@tgross35```````
CI: free disk with in-tree script instead of GitHub Action
Only assert the `Parser` size on specific arches The size of this struct depends on the alignment of `u128`, for example powerpc64le and s390x have align-8 and end up with only 280 bytes. Our 64-bit tier-1 arches are the same though, so let's just assert on those. r? nnethercote
ci: use 8 core arm runner for dist-aarch64-linux try-job: dist-aarch64-linux
…ts, r=rcvalle Enable kernel sanitizers for aarch64-unknown-none-softfloat We want kernels to be able to use this bare metal target, so let's enable the sanitizers that kernels want to use. cc ```@rcvalle``` ```@ojeda``` ```@maurer```
Rollup of 7 pull requests Successful merges: - #135073 (Implement `ByteStr` and `ByteString` types) - #135492 (Add missing check for async body when suggesting await on futures.) - #135766 (handle global trait bounds defining assoc types) - #135880 (Get rid of RunCompiler) - #135908 (rustc_codegen_llvm: remove outdated asm-to-obj codegen note) - #135911 (Allow `arena_cache` queries to return `Option<&'tcx T>`) - #135920 (simplify parse_format::Parser::ws by using next_if) r? `@ghost` `@rustbot` modify labels: rollup
Do not assume const params are printed after type params Fixes #135737
Rustc dev guide subtree update r? ``@ghost``
Add memory layout documentation to generic NonZero<T> The documentation I've added is based on the same Layout documentation that appears on the other `NonZero*` types. For example see [the Layout docs on `NonZeroI8`](https://doc.rust-lang.org/std/num/type.NonZeroI8.html#layout-1).
Use short type string in E0308 secondary span label
We were previously printing the full type on the "this expression has type" label.
```
error[E0308]: mismatched types
--> $DIR/secondary-label-with-long-type.rs:8:9
|
LL | let () = x;
| ^^ - this expression has type `((..., ..., ..., ...), ..., ..., ...)`
| |
| expected `((..., ..., ..., ...), ..., ..., ...)`, found `()`
|
= note: expected tuple `((..., ..., ..., ...), ..., ..., ...)`
found unit type `()`
= note: the full type name has been written to '$TEST_BUILD_DIR/diagnostic-width/secondary-label-with-long-type/secondary-label-with-long-type.long-type-3987761834644699448.txt'
= note: consider using `--verbose` to print the full type name to the console
```
Reported in a comment of #135919.
Don't drop types with no drop glue when building drops for tailcalls
this is required as otherwise drops of `&mut` refs count as a usage of a
'two-phase temporary' causing an ICE.
fixes #128097
The underlying issue is that the current code generates drops for `&mut` which are later counted as a second use of a two-phase temporary:
`bat t.rs -p`
```rust
#![expect(incomplete_features)]
#![feature(explicit_tail_calls)]
fn f(x: &mut ()) {
let _y = String::new();
become f(x);
}
fn main() {}
```
`rustc t.rs -Zdump_mir=f`
```text
error: internal compiler error: compiler/rustc_borrowck/src/borrow_set.rs:298:17: found two uses for 2-phase borrow temporary _4: bb2[1] and bb3[0]
--> t.rs:6:5
|
6 | become f(x);
| ^^^^^^^^^^^
thread 'rustc' panicked at compiler/rustc_borrowck/src/borrow_set.rs:298:17:
Box<dyn Any>
stack backtrace:
[REDACTED]
error: aborting due to 1 previous error
```
`bat ./mir_dump/t.f.-------.renumber.0.mir -p -lrust`
```rust
// MIR for `f` 0 renumber
fn f(_1: &mut ()) -> () {
debug x => _1;
let mut _0: ();
let mut _2: !;
let _3: std::string::String;
let mut _4: &mut ();
scope 1 {
debug _y => _3;
}
bb0: {
StorageLive(_3);
_3 = String::new() -> [return: bb1, unwind: bb4];
}
bb1: {
FakeRead(ForLet(None), _3);
StorageLive(_4);
_4 = &mut (*_1);
drop(_3) -> [return: bb2, unwind: bb3];
}
bb2: {
StorageDead(_3);
tailcall f(Spanned { node: move _4, span: t.rs:6:14: 6:15 (#0) });
}
bb3 (cleanup): {
drop(_4) -> [return: bb4, unwind terminate(cleanup)];
}
bb4 (cleanup): {
resume;
}
}
```
Note how `_4 is moved into the tail call in `bb2` and dropped in `bb3`.
This PR adds a check that the locals we drop need dropping.
r? `@oli-obk` (feel free to reassign, I'm not sure who would be a good reviewer, but thought you might have an idea)
cc `@beepster4096,` since you wrote the original drop implementation.
…t, r=notriddle [rustdoc] Fix indent of trait items on mobile Before:  After:  Seems like we forgot them when we did #131718. Can be tested [here](https://rustdoc.crud.net/imperio/fix-trait-items-mobile-indent/foo/trait.T.html). r? `@notriddle`
Rollup of 9 pull requests Successful merges: - #135415 (Add `File already exists` error doc to `hard_link` function) - #135581 (Separate Builder methods from tcx) - #135728 (document order of items in iterator from drain) - #135749 (Do not assume const params are printed after type params) - #135829 (Rustc dev guide subtree update) - #135938 (Add memory layout documentation to generic NonZero<T>) - #135949 (Use short type string in E0308 secondary span label) - #135976 (Don't drop types with no drop glue when building drops for tailcalls) - #135998 ([rustdoc] Fix indent of trait items on mobile) r? `@ghost` `@rustbot` modify labels: rollup
Update cargo 5 commits in 045bf21b36a2e1f3ed85e38278d1c3cc4305e134..cecde95c119a456c30e57d3e4b31fff5a7d83df4 2025-01-17 14:59:36 +0000 to 2025-01-24 17:15:24 +0000 - Remove unused `-C link-arg=-fuse-ld=lld` (rust-lang/cargo#15097) - Remove `unsafe` by using `LazyLock` (rust-lang/cargo#15096) - Print globs when workspace members can't be found (rust-lang/cargo#15093) - Make --allow-dirty imply --allow-staged (rust-lang/cargo#15013) - fix(config): When merging, replace rather than combining specific configuration keys (rust-lang/cargo#15066)
…pkin Add `#[optimize(none)]` cc #54882 This extends the `optimize` attribute to add `none`, which corresponds to the LLVM `OptimizeNone` attribute. Not sure if an MCP is required for this, happy to file one if so.
Automatic Rustup
Reword resolve errors caused by likely missing crate in dep tree Reword label and add `help`: ``` error[E0432]: unresolved import `some_novel_crate` --> f704.rs:1:5 | 1 | use some_novel_crate::Type; | ^^^^^^^^^^^^^^^^ use of unresolved module or unlinked crate `some_novel_crate` | = help: if you wanted to use a crate named `some_novel_crate`, use `cargo add some_novel_crate` to add it to your `Cargo.toml` ``` Fix #133137.
show linker output even if the linker succeeds Show stderr and stderr by default, controlled by a new `linker_messages` lint. fixes rust-lang/rust#83436. fixes rust-lang/rust#38206. cc https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/uplift.20some.20-Zverbose.20calls.20and.20rename.20to.E2.80.A6.20compiler-team.23706/near/408986134 <!-- try-job: dist-x86_64-msvc --> try-job: aarch64-apple r? `@bjorn3`
Get rid of `mir::Const::from_ty_const` This function is strange, because it turns valtrees into `mir::Const::Value`, but the rest of the const variants stay as type system consts. All of the callsites except for one in `instsimplify` (array length simplification of `ptr_metadata` call) just go through the valtree arm of the function, so it's easier to just create a `mir::Const` directly for those. For the instsimplify case, if we have a type system const we should *keep* having a type system const, rather than turning it into a `mir::Const::Value`; it doesn't really matter in practice, though, bc `usize` has no padding, but it feels more principled.
Fix tests on LLVM 20 For sparcv8plus.rs, duplicate the test for LLVM 19 and LLVM 20. LLVM 20 resolves one of the FIXME in the test. For x86_64-bigint-add.rs split the check lines for LLVM 19 and LLVM 20. The difference in codegen here is due to a difference in unroll factor, which I believe is not what the test is interested in. Fixes rust-lang/rust#132957. Fixes rust-lang/rust#133754.
compiler_fence: fix example The old example was wrong, an acquire fence is required in the signal handler. To make the point more clear, I changed the "data" variable to use non-atomic accesses. Fixes rust-lang/rust#133014
Add some tracing to core bootstrap logic Follow-up to #135391. ### Summary Add some initial tracing logging to bootstrap, focused on the core logic (in this PR). Also: - Adjusted tracing-tree style to not use indent lines (I found that more distracting than helpful). - Avoid glob-importing `tracing` items. - Improve the rustc-dev-guide docs on bootstrap tracing. ### Example output ```bash $ BOOTSTRAP_TRACING=bootstrap=TRACE ./x check src/bootstrap ```  r? bootstrap
rustc_ast: replace some len-checks + indexing with slice patterns etc.
triagebot: set myself on vacation Will be back 02-01.
Rollup of 8 pull requests Successful merges: - #126604 (Uplift `clippy::double_neg` lint as `double_negations`) - #135158 (Add `TooGeneric` variant to `LayoutError` and emit `Unknown`) - #135635 (Move `std::io::pipe` code into its own file) - #136072 (add two old crash tests) - #136079 (compiler_fence: fix example) - #136091 (Add some tracing to core bootstrap logic) - #136097 (rustc_ast: replace some len-checks + indexing with slice patterns etc.) - #136101 (triagebot: set myself on vacation) r? `@ghost` `@rustbot` modify labels: rollup
Update rustc_codegen_gcc subtree cc `@antoyo`
Downgrade `linker-warnings` to allow-by-default This needs more time to bake before we turn it on. Turning it on early risks people silencing the warning indefinitely, before we have the chance to make it less noisy. cc rust-lang/rust#136096 fixes rust-lang/rust#136086 (comment) r? `@saethlin` cc `@Noratrieb` `@bjorn3` `@rustbot` label A-linkage L-linker_messages
Miri subtree update r? `@ghost`
…eywiser Windows x86: Change i128 to return via the vector ABI Clang and GCC both return `i128` in xmm0 on windows-msvc and windows-gnu. Currently, Rust returns the type on the stack. Add a calling convention adjustment so we also return scalar `i128`s using the vector ABI, which makes our `i128` compatible with C. In the future, Clang may change to return `i128` on the stack for its `-msvc` targets (more at [1]). If this happens, the change here will need to be adjusted to only affect MinGW. Link: rust-lang/rust#134288 (does not fix) [1] try-job: x86_64-msvc try-job: x86_64-msvc-ext1 try-job: x86_64-mingw-1 try-job: x86_64-mingw-2
|
Hm, the first commit is like a stray 7 days away from the second commit. The actual changes look good to me, not 100% on the commit history though. |
|
ah the commit from 2 weeks ago is because they were authored 2 weeks ago but were commited recently in rust-lang/rust#135489 (so couldn't have been in the previous rustc-pull). I think this is fine 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
bot didnt auto open a PR this week
@Kobzol @jieyouxu would be nice to have someone do a look over the changes. I think its fine though