minor: Rustc pull update #21268
Merged
minor: Rustc pull update #21268
+124
−4
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
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 8231065 Filtered ref: e13c0be8f13737c64082b89ce834546079767ac4 This merge was created using https://github.com/rust-lang/josh-sync.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: ffb9d94 Filtered ref: 2f31646593733abae36e4c05b5a54acfb9f1f6bc This merge was created using https://github.com/rust-lang/josh-sync.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: d36f964 Filtered ref: 92461731ae79cfe5044e4826160665b77c0363a2 This merge was created using https://github.com/rust-lang/josh-sync.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: caccb4d Filtered ref: 3074203aaad351997a9863b04e251efa3e4b5f6e Upstream diff: rust-lang/rust@9385c64...caccb4d This merge was created using https://github.com/rust-lang/josh-sync.
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to d690155. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
Implement `clamp_magnitude` method for primitive floats & signed integers Tracking issue rust-lang/rust#148519 ACP rust-lang/libs-team#686
stabilize maybe_uninit_slice Tracking issue: rust-lang/rust#63569 Closes: rust-lang/rust#63569 FCP completed: rust-lang/rust#63569 (comment) Removes: ```rs pub const fn slice_as_ptr(this: &[MaybeUninit<T>]) -> *const T; pub const fn slice_as_mut_ptr(this: &mut [MaybeUninit<T>]) -> *mut T; ```
cmse: do not calculate the layout of a type with infer types tracking issue: rust-lang/rust#81391 tracking issue: rust-lang/rust#75835 fixes rust-lang/rust#130104 Don't calculate the layout of a type with an infer type (`_`). This now emits `LayoutError::Unknown`, causing an error similar to when any other calling convention is used in this location. The tests use separate functions because only the first such error in a function body is reported. r? `@davidtwco` (might need some T-types assistance)
Fudge infer vars in the cause code of `Obligation` intentionally Fixes the ICE variant in rust-lang/trait-system-refactor-initiative#245. Fixes rust-lang/rust#142866. The detailed cause is in the test comments. r? `@lcnr`
Don't suggest unwrap for Result in const close rust-lang/rust#149316 Regarding `const fn` that returns `Result`, we should avoid suggesting unwrapping. The original issue reported cases where types didn't match, but in practice, such suggestions may also appear when methods are not found, so this PR includes a fix for that case as well.
fix(parse): Limit frontmatter fences to 255 dashes Like raw string literals. As discussed on rust-lang/rust#148051. Part of rust-lang/rust#136889
Rollup of 9 pull requests Successful merges: - rust-lang/rust#148690 (Implement `clamp_magnitude` method for primitive floats & signed integers) - rust-lang/rust#149102 (stabilize maybe_uninit_slice) - rust-lang/rust#149269 (cmse: do not calculate the layout of a type with infer types) - rust-lang/rust#149299 (Fudge infer vars in the cause code of `Obligation` intentionally) - rust-lang/rust#149344 (Don't suggest unwrap for Result in const) - rust-lang/rust#149358 (fix(parse): Limit frontmatter fences to 255 dashes ) - rust-lang/rust#149445 (make assoc fn inherit const stability from inherent `const impl` blocks) - rust-lang/rust#149479 (Fix indent in E0591.md) - rust-lang/rust#149496 (Fix rust-lang/rust#148889: Add label rib when visiting delegation body) r? `@ghost` `@rustbot` modify labels: rollup
expand valid edition range for use-path-segment-kw.rs
Make the capitalization explicit on keyword misspell error Will help for rust-lang/rust#149405.
Use a delayed bug for this layout ICE Fixes rust-lang/rust#144501 cc `@matthiaskrgr`
Tidying up UI tests [7/N] > [!NOTE] > Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge. part of rust-lang/rust#133895 removed directory `tests/ui/explicit`, `tests/ui/interior-mutability`, `tests/ui/invalid-module-declaration`, tests/ui/invalid-self-argument` r? Kivooeo
Update the comment in the add_typo_suggestion function This comment was added to rust-lang/rust@089810a. However, the test for the comment was moved elsewhere in rust-lang/rust#145897.
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to f25db55. Created using https://github.com/rust-lang/josh-sync. r? `@ghost` Last one for now...
Rollup of 6 pull requests Successful merges: - rust-lang/rust#149393 (expand valid edition range for use-path-segment-kw.rs) - rust-lang/rust#149427 (Make the capitalization explicit on keyword misspell error) - rust-lang/rust#149433 (Use a delayed bug for this layout ICE) - rust-lang/rust#149473 (Tidying up UI tests [7/N]) - rust-lang/rust#149505 (Update the comment in the add_typo_suggestion function) - rust-lang/rust#149513 (`rust-analyzer` subtree update) r? `@ghost` `@rustbot` modify labels: rollup
Compute jump threading opportunities in a single pass The current implementation of jump threading walks MIR CFG backwards from each `SwitchInt` terminator. This PR replaces this by a single postorder traversal of MIR. In theory, we could do a full fixpoint dataflow analysis, but this has low returns as we forbid threading through a loop header. The second commit in this PR modifies the carried state to a lighter data structure. The current implementation uses some kind of `IndexVec<ValueIndex, &[Condition]>`. This is needlessly heavy, as the state rarely ever carries more than a few `Condition`s. The first commit replaces this state with a simpler `&[Condition]`, and puts the corresponding `ValueIndex` inside `Condition`. The three later commits are perf tweaks. The sixth commit is the main change. Instead of carrying the goto target inside the condition, we maintain a set of conditions associated with each block, and their consequences in following blocks. Think: if this condition is fulfilled in this block, then that condition is fulfilled in that block. This makes the threading algorithm much easier to implement, without the extra bookkeeping of `ThreadingOpportunity` we had. Later commits modify that algorithm to shrink the set of duplicated blocks. By propagating fulfilled conditions down the CFG, and trimming costly threads.
…elmann Move even more early buffered lints to dyn lint diagnostics Follow-up to rust-lang/rust#145881 and rust-lang/rust#145747. I originally wanted to migrate most if not the entire rest of the early buffered lints. However, when trying to migrate the buffered lints used by check-cfg I encountered a roadblock. Namely, it depends on `TyCtxt` (well, `Option<TyCtxt>`) which makes it quite hard to migrate (see also rust-lang/rust#147634 (comment), rust-lang/rust#147634 (comment) & rust-lang/rust#149215). So for now, I won't migrate it (maybe rust-lang/rust#149215 will find a solution), nor will I migrate the rest since it's quite tedious to migrate these. I'll leave them for future me.
Bring back i686-pc-windows-gnullvm target rust-lang/rust#148751 inadvertently removed i686-pc-windows-gnullvm std build when migrating to native CI runners. Since this change was not agreed upon, we should bring back prebuilt std builds for that target. There are a few runners that could do it: dist-aarch64-llvm-mingw, dist-x86_64-llvm-mingw, dist-various-1 and dist-various-2. dist-x86_64-llvm-mingw already takes slightly over 2 hours, so the faster dist-aarch64-llvm-mingw is a better choice. We can also use dist-various-x job, they don't have llvm-mingw toolchain, but it's trivial to install one.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 47cd7120d9b4e1b64eb27c87522a07888197fae8 Filtered ref: b5a5cb8beb5c1ac848a39bfcd0ccaad98015d017 Upstream diff: rust-lang/rust@caccb4d...47cd712 This merge was created using https://github.com/rust-lang/josh-sync.
In `BTreeMap::eq`, do not compare the elements if the sizes are different. Reverts rust-lang/rust#147101 in library/alloc/src/btree/ rust-lang/rust#147101 replaced some instances of code like `a.len() == b.len() && a.iter().eq(&b)` with just `a.iter().eq(&b)`, but the optimization that PR introduced only applies for `TrustedLen` iterators, and `BTreeMap`'s itertors are not `TrustedLen`, so this theoretically regressed perf for comparing large `BTreeMap`/`BTreeSet`s with unequal lengths but equal prefixes, (and also made it so that comparing two different-length `BTreeMap`/`BTreeSet`s with elements whose `PartialEq` impls that can panic now can panic, though this is not a "promised" behaviour either way (cc rust-lang/rust#149122)) Given that `TrustedLen` is an unsafe trait, I opted to not implement it for `BTreeMap`'s iterators, and instead just revert the change. If someone else wants to audit `BTreeMap`'s iterators to make sure they always return the right number of items (even in the face of incorrect user `Ord` impls) and then implement `TrustedLen` for them so that the optimization works for them, then this can be closed in favor of that (or if the perf regression is deemed too theoretical, this can be closed outright). Example of theoretical perf regression: https://play.rust-lang.org/?version=beta&mode=release&edition=2024&gist=a37e3d61e6bf02669b251315c9a44fe2 (very rough estimates, using `Instant::elapsed`). In release mode on stable the comparison takes ~23.68µs. In release mode on beta/nightly the comparison takes ~48.351057ms.
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to 633cff2. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
…cro-gen-147648, r=JonathanBrouwer Fix unused_assignments false positives from macros Fixes rust-lang/rust#147648
Use `TypingMode::PostAnalysis` in `try_evaluate_const` As mentioned in rust-lang/rust#148698 (comment), we should use ``TypingMode::PostAnalysis`` for that path. ````@BoxyUwU```` prefer the match in ``try_evaluate_const`` to be exhaustive, so I also included that in this PR :3
std: don't call `current_os_id` from signal handler `current_os_id` is not always async-signal-safe depending on the platform, hence it may not be called from the SIGSEGV handler. Instead, store the thread ID along with the thread name during setup. With rust-lang/rust#144465 merged, this information is available even before the thread main function.
…li-obk CTFE: avoid emitting a hard error on generic normalization failures Fixes rust-lang/rust#149081. The fix is quite unsatisfying and should not be necessary, cc rust-lang/rust#149283. That change is significantly more involved. This temporary fix introduces some unnecessary complexity and may hide other type system bugs. cc ````@rust-lang/types```` I think we should try to fix issue rust-lang/rust#149283 in the near future and then remove this hack again. I originally intended a more targeted fix. I wanted to skip evaluating constants in MIR opts if their body was polymorphic and the current generic arguments still reference generic parameters. Notes from looking into this: - we only fetch the MIR in the `eval_to_allocation_raw` query - figuring out which MIR to use is hard - dealing with trivial consts is annoying - need to resolve instances for associated consts - implementing this by hand is hard - inlining handles this issue by bailing on literally all normalization failures, even the ones that imply an unsoundness - `try_normalize_after_erasing_regions` generally does two things - deal with ambiguity after inlining - deal with error tainting issues (please don't, we should stop doing that) - CTFE could be changed to always silently ignore normalization failures if we're in a generic body - hides actual bugs <- went with this option r? types
…acrum
Additional test for uN::{gather,scatter}_bits
Feature gate: #![feature(uint_gather_scatter_bits)]
Tracking issue: rust-lang/rust#149069
Accepted ACP: rust-lang/libs-team#695 (comment)
Adds an additional runtime test for `uN::gather_bits` and `uN::scatter_bits` in coretests. They are each other's inverses in a sense, so a shared test can test both with relative ease.
I plan to follow up with optimized implementations for these functions.
`c_variadic`: make `VaList` abi-compatible with C tracking issue: rust-lang/rust#44930 related PR: rust-lang/rust#144529 On some platforms, the C `va_list` type is actually a single-element array of a struct (on other platforms it is just a pointer). In C, arrays passed as function arguments expirience array-to-pointer decay, which means that C will pass a pointer to the array in the caller instead of the array itself, and modifications to the array in the callee will be visible to the caller (this does not match Rust by-value semantics). However, for `va_list`, the C standard explicitly states that it is undefined behaviour to use a `va_list` after it has been passed by value to a function (in Rust parlance, the `va_list` is moved, not copied). This matches Rust's pass-by-value semantics, meaning that when the C `va_list` type is a single-element array of a struct, the ABI will match C as long as the Rust type is always be passed indirectly. In the old implementation, this ABI was achieved by having two separate types: `VaList` was the type that needed to be used when passing a `VaList` as a function parameter, whereas `VaListImpl` was the actual `va_list` type that was correct everywhere else. This however is quite confusing, as there are lots of footguns: it is easy to cause bugs by mixing them up (e.g. the C function `void foo(va_list va)` was equivalent to the Rust `fn foo(va: VaList)` whereas the C function `void bar(va_list* va)` was equivalent to the Rust `fn foo(va: *mut VaListImpl)`, not `fn foo(va: *mut VaList)` as might be expected); also converting from `VaListImpl` to `VaList` with `as_va_list()` had platform specific behaviour: on single-element array of a struct platforms it would return a `VaList` referencing the original `VaListImpl`, whereas on other platforms it would return a cioy, In this PR, there is now just a single `VaList` type (renamed from `VaListImpl`) which represents the C `va_list` type and will just work in all positions. Instead of having a separate type just to make the ABI work, rust-lang/rust#144529 adds a `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute, which when applied to a struct will force the struct to be passed indirectly by non-Rustic calling conventions. This PR then implements the `VaList` rework, making use of the new attribute on all platforms where the C `va_list` type is a single-element array of a struct. Cleanup of the `VaList` API and implementation is also included in this PR: since it was decided it was OK to experiment with Rust requiring that not calling `va_end` is not undefined behaviour (rust-lang/rust#141524 (comment)), I've removed the `with_copy` method as it was redundant to the `Clone` impl (the `Drop` impl of `VaList` is a no-op as `va_end` is a no-op on all known platforms). Previous discussion: rust-lang/rust#141524 and [t-compiler > c_variadic API and ABI](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/c_variadic.20API.20and.20ABI) Tracking issue: rust-lang/rust#44930 r? `@joshtriplett`
Assume the returned value in `.filter(…).count()` Similar to how this helps in `slice::Iter::position`, LLVM sometimes loses track of how high this can get, so for `TrustedLen` iterators tell it what the upper bound is.
…eLapkin early return on duplicate span lowerings `@bors2` try
Implement blessing for tidy alphabetical check r? `@jdonszelmann`
Improve error message for std integer clamp() if min > max For rust-lang/rust#142309: change the error message for `Ord::clamp()` for std integer types if min > max to be more useful. Message is now `min > max. min = {min:?}, max = {max:?}` Also add `#[track_caller]` to `clamp()`
`rust-analyzer` subtree update Subtree update of `rust-analyzer` to 5e3e9c4. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
Subtree sync for rustc_codegen_cranelift The main highlights this time are a Cranelift update and adding actual support for `-Cdebuginfo=line-tables-only` rather than treating it the same as `-Cdebuginfo=full`. r? `@ghost` `@rustbot` label +A-codegen +A-cranelift +T-compiler
Move the libgccjit.so file in a target directory Since GCC is not multi-target, we need multiple libgccjit.so. Our solution to have a directory per target so that we can have multiple libgccjit.so. r? `@Kobzol`
std: Use more `unix.rs` code on WASI targets
This commit is a large change to the implementation of filesystem and
other system-related operations on WASI targets. Previously the standard
library explicitly used the `wasi` crate at the 0.11.x version track
which means that it used WASIp1 APIs directly. This meant that `std` was
hard-coded to use WASIp1 syscalls and there was no separate
implementation for the WASIp{2,3} targets, for example. The high-level
goal of this commit is to decouple this interaction and avoid the use of
the `wasi` crate on the WASIp2 target.
Historically when WASIp1 was originally added to Rust the wasi-libc
library was in a much different position than it is today. Nowadays Rust
already depends on wasi-libc on WASI targets for things like memory
allocation and environment variable management. As a libc library it
also has all the functions necessary to implement all filesystem
operations Rust wants. Recently wasi-libc additionally was updated to
use WASIp2 APIs directly on the `wasm32-wasip2` target instead of using
`wasm32-wasip1` APIs. This commit is leveraging this work by enabling
Rust to completely sever the dependence on WASIp1 APIs when compiling
for `wasm32-wasip2`. This is also intended to make it easier to migrate
to `wasm32-wasip3` internally in the future where now only libc need be
updated and Rust doesn't need to explicitly change as well.
The overall premise of this commit is that there's no need for
WASI-specific implementation modules throughout the standard library.
Instead the libc-style bindings already implemented for Unix-like
targets are sufficient. This means that Rust will now be using
libc-style interfaces to interact with the filesystem, for example, and
wasi-libc is the one responsible for translating these POSIX-ish
functions into WASIp{1,2} calls.
Concrete changes here are:
* `std` for `wasm32-wasip2` no longer depends on `wasi 0.11.x`
* The implementation of `std::os::wasi::fs`, which was previously
unstable and still is, now has portions gated to only work on the
WASIp1 target which use the `wasi` crate directly. Traits have been
trimmed down in some cases, updated in others, or now present a
different API on WASIp1 and WASIp2. It's expected this'll get further
cleanup in the future.
* The `std::sys::fd::wasi` module is deleted and `unix` is used instead.
* The `std::sys::fs::wasi` module is deleted and `unix` is used instead.
* The `std::sys::io::io_slice::wasi` module is deleted and `unix` is used
instead.
* The `std::sys::pal::{wasip1,wasip2}` modules are now merged together
as their difference is much smaller than before.
* The `std::sys::pal::wasi::time` is deleted and the `unix` variant is
used directly instead.
* The `std::sys::stdio::wasip{1,2}` modules are deleted and the `unix`
variant is used instead.
* The `std::sys::thread::wasip{1,2}` modules are deleted and the `unix`
variant is used instead.
Overall Rust's libstd is effectively more tightly bound to libc when
compiled to WASI targets. This is intended to mirror how it's expected
all other languages will also bind to WASI. This additionally has the
nice goal of drastically reducing the WASI-specific maintenance burden
in libstd (in theory) and the only real changes required here are extra
definitions being added to `libc` (done in separate PRs). This might be
required for more symbols in the future but for now everything should be
mostly complete.
…r=nnethercote Revert "early return on duplicate span lowerings" r? `@nnethercote` reverts rust-lang/rust#149060 because of perf regressions that are still wild to me
…tebank Deduplicate higher-ranked lifetime capture errors in impl Trait Previously, when an `impl Trait` captured multiple higher-ranked lifetimes from an outer `impl Trait`, the compiler would emit a separate error for each captured lifetime. This resulted in verbose and confusing diagnostics, especially in edition 2024 where implicit captures caused duplicate errors. This commit introduces error accumulation that collects all capture spans and lifetime declaration spans, then emits a single consolidated diagnostic using MultiSpan. The new error shows all captured lifetimes with visual indicators and lists all declarations in a single note. r? `@estebank` Fixes rust-lang/rust#143022
…r, r=lcnr
Move `struct Placeholder<T>`
r? ghost
Couple of issues I've encountered;
- `compiler/rustc_infer/src/infer/region_constraints/mod.rs` `GenericKind` I can't call `write!(f, "{p}")` due to error 1. Which looks like I may need to implement `Lift` for `Placeholder`?
- Using the `define_print_and_forward_display!` for `ty::PlaceholderType` caused error 2, as I've moved the struct it no longer exists in the crate. I suspect because I'm not using that macro it causes the error for `GenericKind`
<details>
<summary>Error 1</summary>
```
error: lifetime may not live long enough
--> compiler/rustc_infer/src/infer/region_constraints/mod.rs:672:38
|
668 | impl<'tcx> fmt::Display for GenericKind<'tcx> {
| ---- lifetime `'tcx` defined here
...
672 | GenericKind::Placeholder(ref p) => write!(f, "{p}"),
| ^^^^^ assignment requires that `'tcx` must outlive `'static`
|
= note: requirement occurs because of the type `rustc_middle::ty::TyCtxt<'_>`, which makes the generic argument `'_` invariant
= note: the struct `rustc_middle::ty::TyCtxt<'tcx>` is invariant over the parameter `'tcx`
= help: see <https://doc.rust-lang.org/nomicon/subtyping.html> for more information about variance
error: implementation of `Lift` is not general enough
--> compiler/rustc_infer/src/infer/region_constraints/mod.rs:672:38
|
672 | GenericKind::Placeholder(ref p) => write!(f, "{p}"),
| ^^^^^ implementation of `Lift` is not general enough
|
= note: `Lift<rustc_middle::ty::TyCtxt<'0>>` would have to be implemented for the type `rustc_type_ir::Placeholder<rustc_middle::ty::TyCtxt<'_>, BoundTy>`, for any lifetime `'0`...
= note: ...but `Lift<rustc_middle::ty::TyCtxt<'1>>` is actually implemented for the type `rustc_type_ir::Placeholder<rustc_middle::ty::TyCtxt<'1>, BoundTy>`, for some specific lifetime `'1`
error: implementation of `Print` is not general enough
--> compiler/rustc_infer/src/infer/region_constraints/mod.rs:672:38
|
672 | GenericKind::Placeholder(ref p) => write!(f, "{p}"),
| ^^^^^ implementation of `Print` is not general enough
```
</details>
<details>
<summary>Error 2</summary>
```
error[E0117]: only traits defined in the current crate can be implemented for arbitrary types
--> compiler/rustc_middle/src/ty/print/pretty.rs:3060:38
|
3057 | / macro_rules! forward_display_to_print {
3058 | | ($($ty:ty),+) => {
3059 | | // Some of the $ty arguments may not actually use 'tcx
3060 | | $(#[allow(unused_lifetimes)] impl<'tcx> fmt::Display for $ty {
| | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
... |
3072 | | };
3073 | | }
| |_- in this expansion of `forward_display_to_print!`
...
3093 | / forward_display_to_print! {
3094 | | ty::Region<'tcx>,
3095 | | Ty<'tcx>,
3096 | | &'tcx ty::List<ty::PolyExistentialPredicate<'tcx>>,
3097 | | ty::Const<'tcx>,
3098 | | &'tcx ty::PlaceholderType<'tcx>
| | ------------------------------- `rustc_type_ir::Placeholder` is not defined in the current crate
3099 | | }
| |_- in this macro invocation
|
= note: impl doesn't have any local type before any uncovered type parameters
= note: for more information see https://doc.rust-lang.org/reference/items/implementations.html#orphan-rules
= note: define and implement a trait or new type instead
error: implementation of `Lift` is not general enough
--> compiler/rustc_middle/src/ty/print/pretty.rs:3060:38
|
3057 | / macro_rules! forward_display_to_print {
3058 | | ($($ty:ty),+) => {
3059 | | // Some of the $ty arguments may not actually use 'tcx
3060 | | $(#[allow(unused_lifetimes)] impl<'tcx> fmt::Display for $ty {
| | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `Lift` is not general enough
... |
3072 | | };
3073 | | }
| |_- in this expansion of `forward_display_to_print!`
...
3093 | / forward_display_to_print! {
3094 | | ty::Region<'tcx>,
3095 | | Ty<'tcx>,
3096 | | &'tcx ty::List<ty::PolyExistentialPredicate<'tcx>>,
3097 | | ty::Const<'tcx>,
3098 | | &'tcx ty::PlaceholderType<'tcx>
3099 | | }
| |_- in this macro invocation
|
= note: `Lift<context::TyCtxt<'0>>` would have to be implemented for the type `rustc_type_ir::Placeholder<context::TyCtxt<'tcx>, BoundTy>`, for any lifetime `'0`...
= note: ...but `Lift<context::TyCtxt<'1>>` is actually implemented for the type `rustc_type_ir::Placeholder<context::TyCtxt<'1>, BoundTy>`, for some specific lifetime `'1`
error: implementation of `print::Print` is not general enough
--> compiler/rustc_middle/src/ty/print/pretty.rs:3060:38
|
3057 | / macro_rules! forward_display_to_print {
3058 | | ($($ty:ty),+) => {
3059 | | // Some of the $ty arguments may not actually use 'tcx
3060 | | $(#[allow(unused_lifetimes)] impl<'tcx> fmt::Display for $ty {
| | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `print::Print` is not general enough
... |
3072 | | };
3073 | | }
| |_- in this expansion of `forward_display_to_print!`
...
3093 | / forward_display_to_print! {
3094 | | ty::Region<'tcx>,
3095 | | Ty<'tcx>,
3096 | | &'tcx ty::List<ty::PolyExistentialPredicate<'tcx>>,
3097 | | ty::Const<'tcx>,
3098 | | &'tcx ty::PlaceholderType<'tcx>
3099 | | }
| |_- in this macro invocation
|
= note: `print::Print<'0, print::pretty::FmtPrinter<'a, '0>>` would have to be implemented for the type `rustc_type_ir::Placeholder<context::TyCtxt<'tcx>, BoundTy>`, for any lifetime `'0`...
= note: ...but `print::Print<'1, print::pretty::FmtPrinter<'a, 'tcx>>` is actually implemented for the type `rustc_type_ir::Placeholder<context::TyCtxt<'1>, BoundTy>`, for some specific lifetime `'1`
error: specializing impl repeats parameter `'tcx`
--> compiler/rustc_middle/src/ty/print/pretty.rs:3060:38
|
3057 | / macro_rules! forward_display_to_print {
3058 | | ($($ty:ty),+) => {
3059 | | // Some of the $ty arguments may not actually use 'tcx
3060 | | $(#[allow(unused_lifetimes)] impl<'tcx> fmt::Display for $ty {
| | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
... |
3072 | | };
3073 | | }
| |_- in this expansion of `forward_display_to_print!`
...
3093 | / forward_display_to_print! {
3094 | | ty::Region<'tcx>,
3095 | | Ty<'tcx>,
3096 | | &'tcx ty::List<ty::PolyExistentialPredicate<'tcx>>,
3097 | | ty::Const<'tcx>,
3098 | | &'tcx ty::PlaceholderType<'tcx>
3099 | | }
| |_- in this macro invocation
error[E0277]: the trait bound `&Placeholder<TyCtxt<'tcx>, BoundTy>: Lift<...>` is not satisfied
--> compiler/rustc_middle/src/ty/print/pretty.rs:3064:30
|
3057 | / macro_rules! forward_display_to_print {
3058 | | ($($ty:ty),+) => {
3059 | | // Some of the $ty arguments may not actually use 'tcx
3060 | | $(#[allow(unused_lifetimes)] impl<'tcx> fmt::Display for $ty {
... |
3064 | | tcx.lift(*self)
| | ---- ^^^^^ unsatisfied trait bound
| | |
| | required by a bound introduced by this call
... |
3072 | | };
3073 | | }
| |_- in this expansion of `forward_display_to_print!`
...
3093 | / forward_display_to_print! {
3094 | | ty::Region<'tcx>,
3095 | | Ty<'tcx>,
3096 | | &'tcx ty::List<ty::PolyExistentialPredicate<'tcx>>,
3097 | | ty::Const<'tcx>,
3098 | | &'tcx ty::PlaceholderType<'tcx>
3099 | | }
| |_- in this macro invocation
|
= help: the trait `Lift<context::TyCtxt<'_>>` is not implemented for `&rustc_type_ir::Placeholder<context::TyCtxt<'tcx>, BoundTy>`
note: required by a bound in `context::TyCtxt::<'tcx>::lift`
--> compiler/rustc_middle/src/ty/context.rs:1807:20
|
1807 | pub fn lift<T: Lift<TyCtxt<'tcx>>>(self, value: T) -> Option<T::Lifted> {
| ^^^^^^^^^^^^^^^^^^ required by this bound in `TyCtxt::<'tcx>::lift`
= note: the full name for the type has been written to '/home/jambar02/Documents/arm/rust/build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/rustc_middle-16e5c44041028d8b.long-type-3843651570422266958.txt'
= note: consider using `--verbose` to print the full type name to the console
help: consider dereferencing here
|
3064 | tcx.lift(**self)
| +
error[E0282]: type annotations needed
--> compiler/rustc_middle/src/ty/print/pretty.rs:3064:21
|
3057 | / macro_rules! forward_display_to_print {
3058 | | ($($ty:ty),+) => {
3059 | | // Some of the $ty arguments may not actually use 'tcx
3060 | | $(#[allow(unused_lifetimes)] impl<'tcx> fmt::Display for $ty {
... |
3064 | |/ tcx.lift(*self)
3065 | || .expect("could not lift for printing")
| ||______________________________________________________________^ cannot infer type
... |
3072 | | };
3073 | | }
| |__- in this expansion of `forward_display_to_print!`
...
3093 | / forward_display_to_print! {
3094 | | ty::Region<'tcx>,
3095 | | Ty<'tcx>,
3096 | | &'tcx ty::List<ty::PolyExistentialPredicate<'tcx>>,
3097 | | ty::Const<'tcx>,
3098 | | &'tcx ty::PlaceholderType<'tcx>
3099 | | }
| |_- in this macro invocation
```
</details>
Run main rust-analyzer tests in rust-lang/rust CI Part of rust-lang/rust#147370. MCP: rust-lang/compiler-team#923 This PR prepares `rust-analyzer` crates with `in-rust-tree` cargo featues where needed, and and updates bootstrap to run the main `rust-analyzer` tests in rust-lang/rust CI, not just the `proc-macro-srv` crate tests. This supersedes the earlier attempt at rust-lang/rust#136779. I was honestly expecting more failures in this PR, but looking back at the previous attempt, that makes sense because we no longer run `i686-mingw` (32-bit windows-gnu) which had a _bunch_ of these failures. In the earlier attempt I also disabled the `i686-mingw`-related failures for `i686-msvc` since I didn't feel like digging into 32-bit msvc at the time. Try results from this PR shows that it's most likely limited to 32-bit windows-gnu specifically. ### `rust-analyzer` test remarks - I actually had to _remove_ the `CARGO_WORKSPACE_DIR` `expect-test`-hack in order for `expect-test` to be able to find the test expectation HTML files (for `syntax_highlighting` tests in `ide`). When I added the hack, ironically, it made `expect-test` unable to find the expectation files. I think this was because previously the path was of the `proc-macro-srv` crate specifically, now we point to the root r-a workspace? - The `cfg`-related differences on `aarch64-apple-darwin` might've been fixed? I can't tell, but we don't seem to be observing the differences now. - I'm not sure why `config::{generate_config_documentation, generate_package_json_config}` no longer fails. Perhaps they were fixed to no longer try to write to source directory? ### Review remarks - Commit 1 updates r-a crates that are involved in tests needing artifacts from `rustc_private` compiler crates to use the `in-rust-tree` cargo feature. I briefly tried to use a plain `--cfg=in_rust_tree`, but quickly realized it was very hacky, and needed invasive bootstrap changes. The cargo feature approach seems most "natural"/well-supported to both bootstrap and cargo. - Commit 2 updates bootstrap to not only run the `proc-macro-srv` tests, but the whole r-a tests. - Commit 3 restricts r-a main tests to non-32-bit targets we test in CI, since (1) r-a repo does not run tests against 32-bit platforms, and (2) there are some target pointer width sensitive hash differences causing tests to fail. Notably, this means that we also no longer run r-a `proc-macro-srv` tests against 32-bit targets, but we don't expect that crate to be have target pointer width differences. Discussed this in [#t-compiler/rust-analyzer > 32-bit tests?](https://rust-lang.zulipchat.com/#narrow/channel/185405-t-compiler.2Frust-analyzer/topic/32-bit.20tests.3F/with/563145736). --- // try-job: aarch64-gnu // try-job: aarch64-apple // try-job: x86_64-mingw-1 // try-job: i686-msvc-1 // try-job: x86_64-msvc-1 // try-job: aarch64-msvc-1
Overhaul filename handling for cross-compiler consistency This PR overhauls the way we handle filenames in the compiler and `rmeta` in order to achieve achieve cross-compiler consistency (ie. having the same path no matter if the filename was created in the current compiler session or is coming from `rmeta`). This is required as some parts of the compiler rely on consistent paths for the soundness of generated code (see rust-lang/rust#148328). In order to achieved consistency multiple steps are being taken by this PR: - by making `RealFileName` immutable - by only having `SourceMap::to_real_filename` create `RealFileName` - currently `RealFileName` can be created from any `Path` and are remapped afterwards, which creates consistency issue - by also making `RealFileName` holds it's working directory, embeddable name and the remapped scopes - this removes the need for a `Session`, to know the current(!) scopes and cwd, which is invalid as they may not be equal to the scopes used when creating the filename In order for `SourceMap::to_real_filename` to know which scopes to apply `FilePathMapping` now takes the current remapping scopes to apply, which makes `FileNameDisplayPreference` and company useless and are removed. This PR is split-up in multiple commits (unfortunately not atomic), but should help review the changes. Unblocks rust-lang/rust#147611 Fixes rust-lang/rust#148328
Update cargo submodule 29 commits in 2c283a9a5c5968eeb9a8f12313f04feb1ff8dfac..e91b2baa632c0c7e84216c91ecfe107c37d887c1 2025-12-04 16:47:28 +0000 to 2025-12-13 16:29:21 +0000 - refactor(lints): move from cargo::util::lints to cargo::lints (rust-lang/cargo#16392) - test(lint): redact more due to line got omitted (rust-lang/cargo#16391) - feat(report): cargo report timings HTML replay (rust-lang/cargo#16377) - feat: stabilize `-Zconfig-include` (rust-lang/cargo#16284) - fix(package): Don't verify registry for --list (rust-lang/cargo#16341) - Fixed incorrect locking logic when artifact-dir == build-dir (rust-lang/cargo#16385) - feat(log): make timing messages ready for HTML replay (rust-lang/cargo#16382) - chore(deps): update msrv (1 version) to v1.92 (rust-lang/cargo#16381) - Downgrade curl-sys to 0.4.83 (rust-lang/cargo#16379) - fix(timing): more self-contained timing/log data (rust-lang/cargo#16378) - test: update to `proc_macro::tracked::path` (rust-lang/cargo#16380) - refactor(lint): move lints to separate modules (rust-lang/cargo#16364) - fix(index): Apply feedback from Cargo team (rust-lang/cargo#16369) - fix(lints): handle lints separately at ws pkg level (rust-lang/cargo#16367) - feat(lint): new `implicit_minimum_version_req` lint (rust-lang/cargo#16321) - fix(info): default to local without explicit reg (rust-lang/cargo#16358) - Remove `[no-mentions]` handler in our triagebot config (rust-lang/cargo#16361) - Don't read the config file twice when $CARGO_HOME is a symlink (rust-lang/cargo#16325) - fix(timings): forgot to negate filter (rust-lang/cargo#16352) - fix(doctest): Include all search paths with new build layout (rust-lang/cargo#16348) - fix(layout): Remove hashes from bins in new layout (rust-lang/cargo#16351) - docs(faq): Include an entry on disk space (rust-lang/cargo#16349) - feat(timings): derive concurrency data from unit data (rust-lang/cargo#16350) - perf(layout): Use unit_id, not pkg hash, for bin/lib pkg_dirs for new layout (rust-lang/cargo#16345) - Validate target source paths before compilation with clearer errors (rust-lang/cargo#16338) - test(doc): Remove unused build script (rust-lang/cargo#16344) - refactor(timings): store UnitData in RenderContext instead (rust-lang/cargo#16346) - perf(clean): Optimize (legacy) clean with multiple -p specifiers (rust-lang/cargo#16264) - test: Adjust output for out-of-tree build-dir (rust-lang/cargo#16343)
NFC normalize lifetime identifiers Fixes rust-lang/rust#126759
Externally implementable items Supersedes rust-lang/rust#140010 Tracking issue: rust-lang/rust#125418 Getting started: ```rust #![feature(eii)] #[eii(eii1)] pub fn decl1(x: u64) // body optional (it's the default) { println!("default {x}"); } // in another crate, maybe #[eii1] pub fn decl2(x: u64) { println!("explicit {x}"); } fn main() { decl1(4); } ``` - tiny perf regression, underlying issue makes multiple things in the compiler slow, not just EII, planning to solve those separately. - No codegen_gcc support, they don't have bindings for weak symbols yet but could - No windows support yet for weak definitions This PR merges the implementation of EII for just llvm + not windows, doesn't yet contain like a new panic handler implementation or alloc handler. With this implementation, it would support implementing the panic handler in terms of EII already since it requires no default implementation so no weak symbols The PR has been open in various forms for about a year now, but I feel that having some implementation merged to build upon
…nkov Don't leak sysroot crates through dependencies Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since rust-lang/rust#110229, but the fix didn't account for sysroot crates. Should fix rust-lang/rust#147966
This updates the rust-version file to 0208ee09be465f69005a7a12c28d5eccac7d5f34.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 0208ee09be465f69005a7a12c28d5eccac7d5f34 Filtered ref: 69b2702 Upstream diff: rust-lang/rust@dfe1b8c...0208ee0 This merge was created using https://github.com/rust-lang/josh-sync.
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
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.
Latest update from rustc.