Rustc pull update #2477
Merged
Rustc pull update #2477
+6
−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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…ub.com/rust-lang/rust Pull recent changes from rust-lang/rust via Josh. Upstream ref: df8102fe5f24f28a918660b0cd918d7331c3896e Filtered ref: 3c30d8cb1ec24e0b8a88a5cedcf6b9bece0117d7
Make `Semantics<'db, DB>` support `Semantics<'db, dyn HirDatabase>`, take two
fix: Do not error at impls for unsized types that do not include `where Self: Sized` items
fix: Hide dyn inlay hints for incomplete `impl`s
fix: Fix completion with some attribute macros
Apply nested goals certainty to `InspectGoals` for normalizes-to ...so that normalizes-to goals don't have `Certainty::Yes` even if they have nested goals which don't hold. r? lcnr
…r-abis, r=ChrisDenton,RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss rust-lang/rust#142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in rust-lang/rust#141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
Implement asymmetrical precedence for closures and jumps I have been through a series of asymmetrical precedence designs in Syn, and finally have one that I like and is worth backporting into rustc. It is based on just 2 bits of state: `next_operator_can_begin_expr` and `next_operator_can_continue_expr`. Asymmetrical precedence is the thing that enables `(return 1) + 1` to require parentheses while `1 + return 1` does not, despite `+` always having stronger precedence than `return` [according to the Rust Reference](https://doc.rust-lang.org/1.83.0/reference/expressions.html#expression-precedence). This is facilitated by `next_operator_can_continue_expr`. Relatedly, it is the thing that enables `(return) - 1` to require parentheses while `return + 1` does not, despite `+` and `-` having exactly the same precedence. This is facilitated by `next_operator_can_begin_expr`. **Example:** ```rust macro_rules! repro { ($e:expr) => { $e - $e; $e + $e; }; } fn main() { repro!{return} repro!{return 1} } ``` `-Zunpretty=expanded` **Before:** ```console fn main() { (return) - (return); (return) + (return); (return 1) - (return 1); (return 1) + (return 1); } ``` **After:** ```console fn main() { (return) - return; return + return; (return 1) - return 1; (return 1) + return 1; } ```
…amelid Merge `Cfg::render_long_html` and `Cfg::render_long_plain` methods common code Follow-up of rust-lang/rust#141747. Thanks `@camelid` for spotting it! r? `@camelid`
Tracking the old name of renamed unstable library features This PR resolves the first problem of rust-lang/rust#141617 : tracking renamed unstable features. The first commit is to add a ui test, and the second one tracks the changes. I will comment on the code for clarification. r? `@jdonszelmann` There have been a lot of PR's reviewed by you lately, thanks for your time! cc `@jyn514`
[AIX] strip underlying xcoff object When stripping, we need to strip the archive member first before archiving. Otherwise, the shared library remain untouched, only the archive symbol table will be modified.
miri: we can use apfloat's mul_add now With rust-lang/rustc_apfloat#11 fixed, there is no reason to still use host floats here. Fixes rust-lang/miri#2995 We already have a test for this: https://github.com/rust-lang/rust/blob/a7153db254acc387e271e75153bdbd3caa2bed89/src/tools/miri/tests/pass/float.rs#L998-L1003 r? ``@oli-obk``
Add bootstrap option to compile a tool with features Add an option to specify which features to build a tool with, e.g. it will be useful to build Miri with tracing enabled: ```toml tool-config.miri.features = ["tracing"] ``` See [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Passing.20--features.20to.20Miri.20build.20using.20.2E.2Fx.2Epy/with/523564773) for the options considered. If the final decision will be different than what I wrote now, I will update the code as needed. The reason why the option is `tool-config.miri.features` instead of something like `tool-features.miri` is to possibly allow adding more tool-specific configurations in the future. I didn't do any validation of the keys of the `tool-config` hashmap, since I saw that no validation is done on the `tools` hashset either. I don't like much the fact that features can be chosen by various places of the codebase: `Step`s can have some fixed `extra_features`, `prepare_tool_cargo` will add features depending on some bootstrapping options, and the newly added option can also contribute features to tools. However I think it is out of scope of this PR to try to refactor all of that (if it even is refactorable), so I left a comment in the codebase explaining all of the sources of features I could find.
rustc-dev-guide subtree update r? `@ghost`
retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features `-Zretpoline` and `-Zretpoline-external-thunk` flags are target modifiers (tracked to be equal in linked crates). * Enables target features for `-Zretpoline-external-thunk`: `+retpoline-external-thunk`, `+retpoline-indirect-branches`, `+retpoline-indirect-calls`. * Enables target features for `-Zretpoline`: `+retpoline-indirect-branches`, `+retpoline-indirect-calls`. It corresponds to clang -mretpoline & -mretpoline-external-thunk flags. Also this PR forbids to specify those target features manually (warning). Issue: rust-lang/rust#116852
add `extern "custom"` functions tracking issue: rust-lang/rust#140829 previous discussion: rust-lang/rust#140566 In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly. The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention. At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this. r? `@traviscross` cc `@tgross35` try-job: x86_64-apple-2
…, r=nikic tests: Split dont-shuffle-bswaps along opt-levels and arches This duplicates dont-shuffle-bswaps in order to make each opt level its own test. Then -opt3.rs gets split into a revision per arch we want to test, with certain architectures gaining new target-cpu minimums.
Add supported asm types for LoongArch32 r? ``````@Amanieu``````
…ering, r=oli-obk assert more in release in `rustc_ast_lowering` My understanding of the compiler's architecture is that in the `ast_lowering` crate, we are constructing the HIR as a one-time thing per crate. This is after tokenizing, parsing, resolution, expansion, possible reparsing, reresolution, reexpansion, and so on. In other words, there are many reasons that perf-focused PRs spend a lot of time touching `rustc_parse`, `rustc_expand`, `rustc_ast`, and then `rustc_hir` and "onwards", but `ast_lowering` is a little bit of an odd duck. In this crate, we have a number of debug assertions. Some are clearly expensive checks that seem like they are prohibitive to run in actual optimized compiler builds, but then there are a number that are simple asserts on integer equalities, `is_empty`, or the like. I believe we should do some of them even in release builds, because the correctness gain is worth the performance cost: almost zero.
Update the stdarch submodule Includes the following changes: * Add s390x z17 target features [1] * Remove `compiler-builtins` from `rustc-dep-of-std` dependencies [2] * Darwin AArch64 detection update [3] * Fixes for the latest nightly [4] * Add a lockfile [5] [1]: rust-lang/stdarch#1826 [2]: rust-lang/stdarch#1825 [3]: rust-lang/stdarch#1827 [4]: rust-lang/stdarch#1830 [5]: rust-lang/stdarch#1829
…mulacrum Update dependencies in `library/Cargo.lock` This removes the `compiler_builtins` dependency from a handful of library dependencies, which is progress toward [1]. [1]: rust-lang/rust#142265
…ulacrum Upgrade `object`, `addr2line`, and `unwinding` in the standard library Object: 0.37.0 is a semver-breaking release but the only breakage is in `elf::R_RISCV_GNU_*` and `pe::IMAGE_WEAK_EXTERN_*` constants, as well as Mach-O dyld. This API is not used by `std`, so we should be fine to upgrade. This new version also includes functionality for parsing Wasm object files that we may eventually like to make use of. Changelog: https://github.com/gimli-rs/object/blob/master/CHANGELOG.md#0370 Addr2line: 0.25.0 is a breaking change only because it upgrades the `gimli` version. It also includes a change to the `compiler-builtins` dependency that helps with [1]. Changelog: https://github.com/gimli-rs/addr2line/blob/master/CHANGELOG.md#0250-20250611 [1]: rust-lang/rust#142265
Rollup of 10 pull requests Successful merges: - rust-lang/rust#134847 (Implement asymmetrical precedence for closures and jumps) - rust-lang/rust#141491 (Delegate `<CStr as Debug>` to `ByteStr`) - rust-lang/rust#141770 (Merge `Cfg::render_long_html` and `Cfg::render_long_plain` methods common code) - rust-lang/rust#142069 (Introduce `-Zmacro-stats`) - rust-lang/rust#142158 (Tracking the old name of renamed unstable library features) - rust-lang/rust#142221 ([AIX] strip underlying xcoff object) - rust-lang/rust#142340 (miri: we can use apfloat's mul_add now) - rust-lang/rust#142379 (Add bootstrap option to compile a tool with features) - rust-lang/rust#142410 (intrinsics: rename min_align_of to align_of) - rust-lang/rust#142413 (rustc-dev-guide subtree update) r? `@ghost` `@rustbot` modify labels: rollup
Clippy subtree update r? `@Manishearth` 1 day late. Got distracted yesterday evening and forgot about it.
Rollup of 9 pull requests Successful merges: - rust-lang/rust#128425 (Make `missing_fragment_specifier` an unconditional error) - rust-lang/rust#135927 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features) - rust-lang/rust#140770 (add `extern "custom"` functions) - rust-lang/rust#142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches) - rust-lang/rust#142248 (Add supported asm types for LoongArch32) - rust-lang/rust#142267 (assert more in release in `rustc_ast_lowering`) - rust-lang/rust#142274 (Update the stdarch submodule) - rust-lang/rust#142276 (Update dependencies in `library/Cargo.lock`) - rust-lang/rust#142308 (Upgrade `object`, `addr2line`, and `unwinding` in the standard library) Failed merges: - rust-lang/rust#140920 (Extract some shared code from codegen backend target feature handling) r? `@ghost` `@rustbot` modify labels: rollup try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-gnu try-job: dist-i586-gnu-i586-i686-musl try-job: test-various
Look at proc-macro attributes when encountering unknown attribute
```
error: cannot find attribute `sede` in this scope
--> $DIR/missing-derive-2.rs:22:7
|
LL | #[sede(untagged)]
| ^^^^
|
help: the derive macros `Deserialize` and `Serialize` accept the similarly named `serde` attribute
|
LL | #[serde(untagged)]
| +
error: cannot find attribute `serde` in this scope
--> $DIR/missing-derive-2.rs:16:7
|
LL | #[serde(untagged)]
| ^^^^^
|
note: `serde` is imported here, but it is a crate, not an attribute
--> $DIR/missing-derive-2.rs:5:1
|
LL | extern crate serde;
| ^^^^^^^^^^^^^^^^^^^
help: `serde` is an attribute that can be used by the derive macros `Serialize` and `Deserialize`, you might be missing a `derive` attribute
|
LL + #[derive(Serialize, Deserialize)]
LL | enum B {
|
```
Partially address #47608. This PR doesn't find [macros that haven't yet been imported by name](rust-lang/rust@af945cb).
Build rustc with assertions in `dist-alt` jobs Revival of rust-lang/rust#131077, to check CI times now that we don't do PGO/BOLT anymore on Linux `-alt` builds. r? `@ghost` try-job: dist-x86_64-msvc-alt try-job: dist-x86_64-linux-alt
…ub.com/rust-lang/rust Pull recent changes from rust-lang/rust via Josh. Upstream ref: d087f112b7d1323446c7b39a8b616aee7fa56b3d Filtered ref: 2d43ce8ac022170e5383f7e5a188b55564b6566a
Temporary lifetime extension through tuple struct and tuple variant constructors
This makes temporary lifetime extension work for tuple struct and tuple variant constructors, such as `Some()`.
Before:
```rust
let a = &temp(); // Extended
let a = Some(&temp()); // Not extended :(
let a = Some { 0: &temp() }; // Extended
```
After:
```rust
let a = &temp(); // Extended
let a = Some(&temp()); // Extended
let a = Some { 0: &temp() }; // Extended
```
So, with this change, this works:
```rust
let a = Some(&String::from("hello")); // New: String lifetime now extended!
println!("{a:?}");
```
Until now, we did not extend through tuple struct/variant constructors (like `Some`), because they are function calls syntactically, and we do not want to extend the String lifetime in:
```rust
let a = some_function(&String::from("hello")); // String not extended!
```
However, it turns out to be very easy to distinguish between regular functions and constructors at the point where we do lifetime extension.
In practice, constructors nearly always use UpperCamelCase while regular functions use lower_snake_case, so it should still be easy to for a human programmer at the call site to see whether something qualifies for lifetime extension or not.
This needs a lang fcp.
---
More examples of what will work after this change:
```rust
let x = Person {
name: "Ferris",
job: Some(&Job { // `Job` now extended!
title: "Chief Rustacean",
organisation: "Acme Ltd.",
}),
};
dbg!(x);
```
```rust
let file = if use_stdout {
None
} else {
Some(&File::create("asdf")?) // `File` now extended!
};
set_logger(file);
```
```rust
use std::path::Component;
let c = Component::Normal(&OsString::from(format!("test-{num}"))); // OsString now extended!
assert_eq!(path.components.first().unwrap(), c);
```
move fast reject into inner to also fast reject inside of the folder r? `@BoxyUwU`
Do not clone Arc when hashing span. Tiny improvement I was when trying to profile span hashing.
early linting: avoid redundant calls to `check_id` An attempt to address the regression at rust-lang/rust#142240 (comment) r? `@oli-obk` cc `@nnethercote` who might have a better understanding of the performance implications
Don't fold `ExternalConstraintsData` when it's empty Probably useless, but let's see. r? lcnr
…-perf-problems, r=oli-obk collect delayed lints in hir_crate_items r? `@oli-obk` Attempt to mitigate perf problems in rust-lang/rust#138164
use `MixedBitSet` for borrows-in-scope dataflow analysis The `Borrows` dataflow analysis uses a dense bitset, but a bitset supporting _some_ amount of sparseness is better suited for big functions with a big number of loans. The cutoff between dense and chunked bitset is around 2K loans IIRC, and we could finesse that value if we wanted to, but as-is it happens to a couple of rustc-perf benchmarks (which IIRC are at least partially generated from macros and the likes.). It's a small win on these two, and shouldn't have any impact on the others. r? `@matthewjasper`
Update to LLVM 20.1.7 Closes rust-lang/rust#141306, closes rust-lang/rust#140686, closes rust-lang/rust#141737, closes rust-lang/rust#140933.
Subtree update of `rust-analyzer` r? `@ghost`
Safer implementation of RepeatN I've seen the "Use MaybeUninit for RepeatN" commit while reading This Week In Rust and immediately thought about something I've written some time ago - https://github.com/Soveu/repeat_finite/blob/master/src/lib.rs. Using the fact, that `Option` will find niche in `(T, NonZeroUsize)`, we can construct something that has the same size as `(T, usize)` while completely getting rid of `MaybeUninit`. This leaves only `unsafe` on `TrustedLen`, which is pretty neat.
…favor-the-target-or-cli, r=jieyouxu Affirm `-Cforce-frame-pointers=off` does not override This PR exists to document that we (that is, the compiler reviewer) implicitly made a decision in rust-lang/rust#86652 that defies the expectations of some programmers. Some programmers believe `-Cforce-frame-pointers=false` should obey the programmer in all cases, forcing the compiler to avoid generating frame pointers, even if the target specification would indicate they must be generated. However, many targets rely on frame pointers for fast or sound unwinding. T-compiler had a weekly triage meeting on 2025-05-22. This topic was put to discussion because some programmers may expect the target-overriding behavior. In that meeting we decided removing frame pointers, at least with regards to the contract of the `-Cforce-frame-pointers` option, is not required, even if `=off` is passed, and that we will not do so if the target would expect them. This follows from the documentation here: https://doc.rust-lang.org/rustc/codegen-options/index.html#force-frame-pointers We may separately pursue trying to clarify the situation more emphatically in our documentation, or warn when people pass the option when it doesn't do anything.
…,traviscross Stabilize `feature(generic_arg_infer)` Fixes rust-lang/rust#85077 r? lcnr cc ````@rust-lang/project-const-generics````
CodeGen: rework Aggregate implemention for rvalue_creates_operand cases A non-trivial refactor pulled out from rust-lang/rust#138759 r? workingjubilee The previous implementation I'd written here based on `index_by_increasing_offset` is complicated to follow and difficult to extend to non-structs. This changes the implementation, without actually changing any codegen (thus no test changes either), to be more like the existing `extract_field` (<https://github.com/rust-lang/rust/blob/2b0274c71dba0e24370ebf65593da450e2e91868/compiler/rustc_codegen_ssa/src/mir/operand.rs#L345-L425>) in that it allows setting a particular field directly. Notably I've found this one much easier to get right, in particular because having the `OperandRef<Result<V, Scalar>>` gives a really useful thing to include in ICE messages if something did happen to go wrong.
…ouxu Clarify bootstrap tools description The existence of `stage0-bootstrap-tools` suggests the possiblity of `stage1/N-bootstrap-tools`, but that's not really a thing. Also it doesn't fit the new bootstrap model, where `stageN` essentially means that it was built with a `stageN-1` compiler (except for std). r? ``@jieyouxu``
remove duplicate crash test I noticed near duplication between "library/alloctests/tests/testing/crash_test.rs" and "library/alloctests/testing/crash_test.rs" and wanted to try and remove that. The only difference is the path used to import `Debug`, but it seems not to matter. Perhaps my change is still wrong? r? ``@bjorn3``
Add `-Z hint-mostly-unused` to tell rustc that most of a crate will go unused This hint allows the compiler to optimize its operation based on this assumption, in order to compile faster. This is a hint, and does not guarantee any particular behavior. This option can substantially speed up compilation if applied to a large dependency where the majority of the dependency does not get used. This flag may slow down compilation in other cases. Currently, this option makes the compiler defer as much code generation as possible from functions in the crate, until later crates invoke those functions. Functions that never get invoked will never have code generated for them. For instance, if a crate provides thousands of functions, but only a few of them will get called, this flag will result in the compiler only doing code generation for the called functions. (This uses the same mechanisms as cross-crate inlining of functions.) This does not affect `extern` functions, or functions marked as `#[inline(never)]`. This option has already existed in nightly as `-Zcross-crate-inline-threshold=always` for some time, and has gotten testing in that form. However, this option is still unstable, to give an opportunity for wider testing in this form. Some performance numbers, based on a crate with many dependencies having just *one* large dependency set to `-Z hint-mostly-unused` (using Cargo's `profile-rustflags` option): A release build went from 4m07s to 2m04s. A non-release build went from 2m26s to 1m28s.
Try unremapping compiler sources See [#t-compiler/help > Span pointing to wrong file location (`rustc-dev` component)](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Span.20pointing.20to.20wrong.20file.20location.20.28.60rustc-dev.60.20component.29/with/521087083). This PR is a follow-up to rust-lang/rust#141751 regarding the compiler side. Specifically we now take into account the `CFG_VIRTUAL_RUSTC_DEV_SOURCE_BASE_DIR` env from rust-lang/rust#141751 when trying to unremap sources from `$sysroot/lib/rustlib/rustc-src/rust` (the `rustc-dev` component install directory). Best reviewed commit by commit. cc ``@samueltardieu`` r? ``@jieyouxu``
remove duplicate crash test I noticed near duplication between "library/alloctests/tests/testing/crash_test.rs" and "library/alloctests/testing/crash_test.rs" and wanted to try and remove that. The only difference is the path used to import `Debug`, but it seems not to matter. Perhaps my change is still wrong? r? ```@bjorn3```
Rollup of 11 pull requests Successful merges: - rust-lang/rust#140774 (Affirm `-Cforce-frame-pointers=off` does not override) - rust-lang/rust#141610 (Stabilize `feature(generic_arg_infer)`) - rust-lang/rust#142383 (CodeGen: rework Aggregate implemention for rvalue_creates_operand cases) - rust-lang/rust#142591 (Add spawn APIs for BootstrapCommand to support deferred command execution) - rust-lang/rust#142619 (apply clippy::or_fun_call) - rust-lang/rust#142624 (Actually take `--build` into account in bootstrap) - rust-lang/rust#142627 (Add `StepMetadata` to describe steps) - rust-lang/rust#142660 (remove joboet from review rotation) - rust-lang/rust#142666 (Skip tidy triagebot linkcheck if `triagebot.toml` doesn't exist) - rust-lang/rust#142672 (Clarify bootstrap tools description) - rust-lang/rust#142674 (remove duplicate crash test) r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 6 pull requests Successful merges: - rust-lang/rust#135656 (Add `-Z hint-mostly-unused` to tell rustc that most of a crate will go unused) - rust-lang/rust#138237 (Get rid of `EscapeDebugInner`.) - rust-lang/rust#141614 (lint direct use of rustc_type_ir ) - rust-lang/rust#142123 (Implement initial support for timing sections (`--json=timings`)) - rust-lang/rust#142377 (Try unremapping compiler sources) - rust-lang/rust#142674 (remove duplicate crash test) r? `@ghost` `@rustbot` modify labels: rollup
{aarch64,x86_64}-pc-windows-gnullvm: build host tools
This is a temporary single-release workflow to create stage0 for these targets.
I opted for bootstrapping from Linux because that's the easiest host system to work with, but once this hits beta, having dedicated Windows runners would be sensible and probably preferable.
`--enable-full-tools` for whatever reason doesn't seem to work when cross-compiling, because LLVM tools for the new hosts are not copied into the expected directory.
rust-lang/compiler-team#877
|
Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using |
rustbot
added
the
S-waiting-on-review
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.
Latest update from rustc.