[pull] master from rust-lang:master #14
Open
Conversation
This file contains 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[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Rollup of 9 pull requests Successful merges: - #136910 (Implement feature `isolate_most_least_significant_one` for integer types) - #137183 (Prune dead regionck code) - #137333 (Use `edition = "2024"` in the compiler (redux)) - #137356 (Ferris 🦀 Identifier naming conventions) - #137362 (Add build step log for `run-make-support`) - #137377 (Always allow reusing cratenum in CrateLoader::load) - #137388 (Fix(lib/fs/tests): Disable rename POSIX semantics FS tests under Windows 7) - #137410 (Use StableHasher + Hash64 for dep_tracking_hash) - #137413 (jubilee cleared out the review queue) r? `@ghost` `@rustbot` modify labels: rollup
Include the match arm guard in the gated span, so that the suggestion to add a body is correct instead of inserting the body before the guard.
Make the suggestion verbose.
```
error: `match` arm with no body
--> $DIR/feature-gate-never_patterns.rs:43:9
|
LL | Some(_) if false,
| ^^^^^^^^^^^^^^^^
|
help: add a body after the pattern
|
LL | Some(_) if false => { todo!() },
| ++++++++++++++
```
Update cargo 16 commits in ce948f4616e3d4277e30c75c8bb01e094910df39..1d1d646c06a84c1aa53967b394b7f1218f85db82 2025-02-14 20:32:07 +0000 to 2025-02-21 21:38:53 +0000 - fix(package): Fix lookups to capitalized workspace member's index entry (rust-lang/cargo#15216) - chore(ci): Visually group output in Github (rust-lang/cargo#15218) - chore(ci): Auto-update cargo-semver-checks (rust-lang/cargo#15212) - chore(deps): update msrv (3 versions) to v1.83 (rust-lang/cargo#15217) - docs(ref): Shift focus to resolver v3 (rust-lang/cargo#15213) - fix: mention "3" as a valid value for "resolver" field in error message (rust-lang/cargo#15215) - chore(deps): update msrv (1 version) to v1.85 (rust-lang/cargo#15211) - fix: build warning in windows_reserved_names_are_allowed (rust-lang/cargo#15206) - Typo: "togother" -> "together" (rust-lang/cargo#15204) - chore: bump to 0.88.0; update changelog (rust-lang/cargo#15202) - Typo: "explicitally" -> "explicitly" (rust-lang/cargo#15201) - fix(add): Focus on error, rather than large feature lists (rust-lang/cargo#15200) - docs: Improve comments (rust-lang/cargo#15197) - fix(embedded): Handle more parsing corner cases (rust-lang/cargo#15187) - docs: docs for `-Zfeature-unification` (rust-lang/cargo#15189) - Fix man page with malformed `{{#options}}` block (rust-lang/cargo#15191)
fix: Binding wrong associated type when lowering bounds like `T: Trait<Assoc = U>`
Update host LLVM to 20.1 on CI r? `@ghost`
Inject `compiler_builtins` during postprocessing and ensure it is made private Follow up of #135278 Do the following: * Inject `compiler_builtins` during postprocessing, rather than injecting `extern crate compiler_builtins as _` into the AST * Do not make dependencies of `std` private by default (this was added in #135278) * Make sure sysroot crates correctly mark their dependencies private/public * Ensure that marking a dependency private makes its dependents private by default as well, unless otherwise specified * Do the `compiler_builtins` update that has been blocked on this There is more detail in the commit messages. This includes the changes I was working on in #136226. try-job: test-various try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: i686-mingw-1 try-job: i686-mingw-2
stabilize `(const_)ptr_sub_ptr` Tracking issue: #95892 Closes #95892 FCP Completed: #95892 (comment) r? ````@Noratrieb````
Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes
There are a few intertwined problems with `sym fn` operands in both inline and global asm macros.
Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length).
Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions:
```rust
fn foo<'a>() {
asm!("/* ... */", sym bar::<&'a ()>);
}
```
The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In #116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication.
In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands.
I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (#137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to #130443 (comment), which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue.
As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts).
r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this.
Fixes #111709
Fixes #96304
Fixes #137179
…ons, r=bjorn3,RalfJung compiler: untangle SIMD alignment assumptions There were a number of puzzling assumptions being made about SIMD types and their layout that I have corrected in this diff. These are mostly no-op edits in actual fact, but they do subtly alter a pair of checks in our invariant-checking and union layout computation that rested on those peculiar assumptions. Those unfortunately stand in the way of any further actual fixes. I submit this for review, even though it's not clearly motivated without its followups, because it should still be possible to independently conclude whether this is correct.
…f, r=Noratrieb stabilize `unsigned_is_multiple_of` tracking issue: #128101 fcp completed in: #128101 (comment) ### Public API A version of this for all the unsigned types ```rust fn is_multiple_of(lhs: u64, rhs: u64) -> bool { match rhs { // prevent division by zero 0 => lhs == 0, _ => lhs % rhs == 0, } } ```
Rollup of 6 pull requests Successful merges: - #135501 (Inject `compiler_builtins` during postprocessing and ensure it is made private) - #137121 (stabilize `(const_)ptr_sub_ptr`) - #137180 (Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes) - #137256 (compiler: untangle SIMD alignment assumptions) - #137383 (stabilize `unsigned_is_multiple_of`) - #137415 (Remove invalid suggestion of into_iter for extern macro) r? `@ghost` `@rustbot` modify labels: rollup
…u,Kobzol stabilize stage management for rustc tools #135990 got out of control due to excessive complexity. This PR aims to achieve the same goal with a simpler approach, likely through multiple smaller PRs. I will keep the other one read-only and open as a reference for future work. This work stabilizes the staging logic for `ToolRustc` programs, so you no longer need to handle build and target compilers separately in steps. Previously, most tools didn't do this correctly, which was causing the compiler to be built twice (e.g., `x test cargo --stage 1` would compile the stage 2 compiler before, but now it only compiles the stage 1 compiler). I also tried to document how we should write `ToolRustc` steps as they are quite different and require more attention than other tools. Next goal is to stabilize how stages are handled for the rustc itself. Currently, `x build --stage 1` builds the stage 1 compiler which is fine, but `x build compiler --stage 1` builds stage 2 compiler. ~~for now, r? ghost~~
Signed-off-by: onur-ozkan <[email protected]>
Removes an ABI hack that used `<2 x i64>` to return `i128` in `xmm0` on Windows [1]. [1]: rust-lang/compiler-builtins#759 Link: #116558 Link: rust-lang/compiler-builtins#758
[Debuginfo] Add MSVC Synthetic and Summary providers to LLDB
Adds handling for `tuple$<>`, `ref$<slice$2<>`, `ref$<str$>` and `enum2$<>`.
Also fixes a bug in MSVC vec/string handling where the script was unable to determine the element's type due to LLDB ignoring template arg debug information
<details>
<summary>Sample code</summary>
```rust
pub enum Number {
One = 57,
Two = 99,
}
#[repr(u8)]
pub enum Container {
First(u32),
Second { val: u64, val2: i8 },
Third,
}
...
let u8_val = b'a';
let float = 42.78000000000001;
let tuple = (u8_val, float);
let str_val = "eef";
let mut string = "freef".to_owned();
let mut_str = string.as_mut_str();
let array: [u8; 4] = [1, 2, 3, 4];
let ref_array = array.as_slice();
let mut array2: [u32; 4] = [1, 2, 3, 4];
let mut_array = array2.as_mut_slice();
let enum_val = Number::One;
let mut enum_val2 = Number::Two;
let sum_val = Container::First(15);
let sum_val_2 = Container::Second { val: 0, val2: 0 };
let sum_val_3 = Container::Third;
let non_zero = NonZeroU128::new(100).unwrap();
let large_discr = NonZeroU128::new(255);
```
</details>
Before:
After:
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1
try-job: i686-mingw
try-job: aarch64-gnu
Replace mem::zeroed with mem::MaybeUninit::uninit for large struct in Unix As discussion in #136737. - Replace `mem::zeroed()` with `MaybeUninit::uninit()` for `sockaddr_storage` in `accept()` and `recvfrom()` since these functions fill in the address structure - Replace `mem::zeroed()` with `MaybeUninit::uninit()` for `pthread_attr_t` in thread-related functions since `pthread_attr_init()` initializes the structure - Add references to man pages to document this behavior
More const {} init in thread_local
`const {}` in `thread_local!` gets an optimization just based on the syntax, rather than the expression being const-compatible. This is easy to miss, so I've added more examples to the docs.
I've also added `const {}` in a couple of places in std where this optimization has been missed.
Enable `f16` for MIPS Blocked on rust-lang/compiler-builtins#762 It seems as if `f16` works on MIPS now according to my testing on Rust master with LLVM 20, and I was asked [here](#137167 (comment)) to create PRs with my changes. I only tested on the flavour of `mipsel-unknown-linux-gnu` hardware that happens to be available to me, so I can't say anything about other MIPS hardware, but from a casual skimming of the LLVM code ([1], [2]) it seems like `f16` should work on all MIPS hardware. So enable it for all MIPS hardware. [1]: https://github.com/rust-lang/llvm-project/blob/rustc/20.1-2025-02-13/llvm/lib/Target/Mips/MipsISelLowering.h#L370 [2]: https://github.com/rust-lang/llvm-project/blob/rustc/20.1-2025-02-13/llvm/lib/CodeGen/TargetLoweringBase.cpp#L1367-L1388 `@rustbot` label +O-MIPS +F-f16_and_f128 +S-blocked Tracking issue for f16: #116909 r? `@tgross35`
…notriddle fix(rustdoc): Fixed stability version in rustdoc Tries to fix #137141 Fixed by adding checks glob exports
remove few unused args
run some tests on emscripten again these were ignored because of #45351, but that issue has long been fixed. Let's see if these pass, or if there is some issue lurking still I believe this is the try-job for emscripten? probably a good idea to run that first. ~~try-job: test-various~~ try-job: dist-various-1
…fmease,bjorn3 ssa/mono: deduplicate `type_has_metadata` The implementation of the `type_has_metadata` function is duplicated in `rustc_codegen_ssa` and `rustc_monomorphize`, so move this to `rustc_middle`.
codegen_llvm: avoid `Deref` impls w/ extern type `rustc_codegen_llvm` relied on `Deref` impls where `Deref::Target` was or contained an extern type - in my experimental implementation of rust-lang/rfcs#3729, this isn't possible as the `Target` associated type's `?Sized` bound cannot be relaxed backwards compatibly (unless we come up with some way of doing this). In later pull requests with the rust-lang/rfcs#3729 implementation, breakage like this could only occur for nightly users relying on the `extern_types` feature. Upstreaming this to avoid needing to keep carrying this patch locally, and I think it'll necessarily need to change eventually.
…ler-errors trait_sel: resolve vars in host effects In the standard library, the `Extend` impl for `Iterator` (specialised with `TrustedLen`) has a parameter which is constrained by a projection predicate. This projection predicate provides a value for an inference variable but - if the default bound is `const Sized` instead of `Sized` - host effect evaluation wasn't resolving variables first. Added a test that doesn't depend on a rust-lang/rfcs#3729 implementation. Adding the extra resolve can the number of errors in some tests when they gain host effect predicates, but this is not unexpected as calls to `resolve_vars_if_possible` can cause more error tainting to happen.
Complete the list of resources used in rustdoc output The Nanum Barun Gothic Font was missing in the list and should clearly be mentionned. Arguably referencing the Rust logos is not really necessary as the file mentions "third party resources" but it doesn't hurt and should make things clearer for anybody who wants to publish their Rust doc.
…r-errors hir_analysis: skip self type of host effect preds in variances_of Discovered as part of an implementation of rust-lang/rfcs#3729 - w/out this then when introducing const trait bounds: many more interesting tests change with different output, missing errors, new errors, etc related to this but they all depend on feature flags and are much more complex than this test. r? ``@oli-obk``
fix doc in library/core/src/pin.rs Fixes #134874
fix attribute-related ICE when parsing macro on the rhs of a name-value attribute r? ``@oli-obk`` Closes: #137589
Rollup of 14 pull requests Successful merges: - #136576 (pass optimization level to llvm-bitcode-linker) - #137154 (Add UTF-8 validation fast paths in `Wtf8Buf`) - #137311 (Enable `f16` for MIPS) - #137320 (fix(rustdoc): Fixed stability version in rustdoc) - #137529 (remove few unused args) - #137544 (tests: Add regression test for derive token invalidation (#81099)) - #137559 (run some tests on emscripten again) - #137601 (ssa/mono: deduplicate `type_has_metadata`) - #137603 (codegen_llvm: avoid `Deref` impls w/ extern type) - #137604 (trait_sel: resolve vars in host effects) - #137609 (Complete the list of resources used in rustdoc output) - #137613 (hir_analysis: skip self type of host effect preds in variances_of) - #137614 (fix doc in library/core/src/pin.rs) - #137622 (fix attribute-related ICE when parsing macro on the rhs of a name-value attribute) r? `@ghost` `@rustbot` modify labels: rollup
To add support for the x87 feature.
Include version number of libs being built in cargo lib metadata (esp. `librustc_driver*.so`) Previously, on a non-stable channel, it's possible for two builds from different versioned sources (e.g. 1.84.0 vs 1.84.1) to produce a `librustc_driver*.so` with the same filename hashes. This causes problems with side-by-side installs wrt. linker search paths because 1.84.1 rustc bin and 1.84.0 rustc bin may try to link to the "same" `librustc_driver*.so` (same filename hash) but fail because the contents of the so is actually different. We try to mitigate this by including the version number of artifacts being built via `__CARGO_DEFAULT_LIB_METADATA` (kind of an ugly hack, but I don't think cargo has a way for us to tell cargo to use a package version override). Fixes #136701 (mitigates, really). ### Testing Tested manually[^host] by: ```bash $ cat src/version 1.86.0 $ ./x build library # w/ compiler profile, (non-stable) dev channel $ lddtree build/host/stage1/bin/rustc rustc => build/host/stage1/bin/rustc (interpreter => /lib64/ld-linux-x86-64.so.2) librustc_driver-ea1b1b2291881cc4.so => build/host/stage1/bin/../lib/librustc_driver-ea1b1b2291881cc4.so [...] ``` and observing that changing `src/version` to bump a point release causes `librustc_driver*.so` to have a different hash while sources are unmodified otherwise. ```bash $ cat src/version 1.86.1 $ ./x build library # w/ compiler profile, (non-stable) dev channel $ lddtree build/host/stage1/bin/rustc rustc => build/host/stage1/bin/rustc (interpreter => /lib64/ld-linux-x86-64.so.2) librustc_driver-746badadbcb74721.so => build/host/stage1/bin/../lib/librustc_driver-746badadbcb74721.so [...] ``` cc `@clan` `@demize` could you check that if you backport this change against 1.84.{0,1} as reported in #136701, that the produced `rustc` binary works, under the context of the Gentoo build system setup? [^host]: on a `x86_64-unknown-linux-gnu` host, no cross
Change interners to start preallocated with an increased capacity Inspired by #137005. Added a `with_capacity` function to `InternedSet`. Changed the `CtxtInterners` to start with `InternedSets` preallocated with a capacity. This *does* increase memory usage at very slightly(by ~1 MB at the start), altough that increase quickly disaperars for larger crates(since they require such capacity anyway). A local perf run indicates this improves compiletimes for small crates(like `ripgrep`), without a negative effect on larger ones.
remove `MaybeUninit::uninit_array` Closes #134584. Closes #66845. The future of this unstable method was described in #125082 (comment). Since `inline_const` was stabilized in 1.79 (4 stable releases away) and no one expressed interest for keeping it in #96097, I think it can be removed now as it is not a stable method.
Use less CString in the examples of CStr. Fixes #83999
Teach structured errors to display short `Ty<'_>`
Make it so that in every structured error annotated with `#[derive(Diagnostic)]` that has a field of type `Ty<'_>`, the printing of that value into a `String` will look at the thread-local storage `TyCtxt` in order to shorten to a length appropriate with the terminal width. When this happen, the resulting error will have a note with the file where the full type name was written to.
```
error[E0618]: expected function, found `((..., ..., ..., ...), ..., ..., ...)``
--> long.rs:7:5
|
6 | fn foo(x: D) { //~ `x` has type `(...
| - `x` has type `((..., ..., ..., ...), ..., ..., ...)`
7 | x(); //~ ERROR expected function, found `(...
| ^--
| |
| call expression requires function
|
= note: the full name for the type has been written to 'long.long-type-14182675702747116984.txt'
= note: consider using `--verbose` to print the full type name to the console
```
Follow up to and response to the comments on #136898.
r? ``@oli-obk``
…Denton Fix `attr` cast for espidf #136826 broke ESP-IDF builds with: https://github.com/esp-rs/esp-idf-template/actions/runs/13516221587/job/37765336588. This PR fixes it. cc: ``@ivmarkov`` ``@xizheyin``
…owLii Don't suggest constraining unstable associated types Fixes #137624 This could be made a bit more specific, considering the local crate's stability or nightly status or something, but I think in general we should not be suggesting associated type bounds on unstable associated items.
Rustc dev guide subtree update r? ``@Kobzol`` ``@jieyouxu``
Update gcc submodule To add support for the x87 feature (see #137612 (comment)). r? `@antoyo`
revert accidental change in get_closest_merge_commit This was accidentally merged as part of #137594. I need this local diff to be able to debug miri syncs, and then typed `git commit -a` too fast and didn't realize it includes this change... sorry for that. r? ``@Kobzol``
Make -Z unpretty=mir suggest -Z dump-mir as well for discoverability While debugging something else, I got quite annoyed with `-Z unpretty=mir` showing me post-processed MIR instead of the one just after it is built. I ended up asking on Zulip and got pointed to `-Z dump-mir`. While this feature is documented in the rustc dev guide, I think it'd be good if the possibility of making use of it was staring you in the face while you need it.
Rollup of 10 pull requests Successful merges: - #134585 (remove `MaybeUninit::uninit_array`) - #136187 (Use less CString in the examples of CStr.) - #137201 (Teach structured errors to display short `Ty<'_>`) - #137620 (Fix `attr` cast for espidf) - #137631 (Avoid collecting associated types for undefined trait) - #137635 (Don't suggest constraining unstable associated types) - #137642 (Rustc dev guide subtree update) - #137660 (Update gcc submodule) - #137670 (revert accidental change in get_closest_merge_commit) - #137671 (Make -Z unpretty=mir suggest -Z dump-mir as well for discoverability) r? `@ghost` `@rustbot` modify labels: rollup
…zkan fixed wast version was released, remove randomization exemption
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )