Update cc-rs to 1.2.39
For my purposes, contains fixes when compiling the Rust compiler for Arm64EC.
Checked the commits since 1.2.16, and I don't see anything else that may affect Rust?
`find-msvc-tools` was also factored out from `cc` to allow updating the use in `rustc_codegen_ssa` (finding the linker when running the Rust compiler) to be separate from the use in `rustc_llvm` (building LLVM as part of the Rust compiler).
CFI: Fix types that implement Fn, FnMut, or FnOnce
When looking for instances which could either be dynamically called through a vtable or through a concrete trait method, we missed `FnPtrShim`, instead only looking at `Item` and closure-likes. Fixesrust-lang/rust#144641.
cc ```@1c3t3a``` ```@Jakob-Koschel```
Do not lifetime-extend array/slice indices
When lowering non-overloaded indexing operations to MIR, this uses the temporary lifetime of the index expression for the index temporary, rather than applying the temporary lifetime of the indexing operation as a whole to the index.
For example, in
```rust
let x = &xs[i];
```
previously, the temporary containing the result of evaluating `i` would live until the end of the block due to the indexing operation being [lifetime-extended](https://doc.rust-lang.org/nightly/reference/destructors.html#temporary-lifetime-extension). Under this PR, the index temporary only lives to the end of the `let` statement because it uses the more precise temporary lifetime of the index expression.
I don't think this will affect semantics in an observable way, but the more precise `StorageDead` placement may slightly improve analysis/codegen performance.
r? mir
When looking for instances which could either be dynamically called
through a vtable or through a concrete trait method, we missed
`FnPtrShim`, instead only looking at `Item` and closure-likes.
Skip codegen_crate call in check mode
This way we don't have to spawn the coordinator thread. Some errors will no longer be emitted with this in check mode. For example the check that `-Ctarget-cpu` is passed on targets that need this.
Suggested by `@saethlin`
Add a fast path for lowering trivial consts
The objective of this PR is to improve compilation performance for crates that define a lot of trivial consts. This is a flamegraph of a build of a library crate that is just 100,000 trivial consts, taken from a nightly compiler:
<img width="842" height="280" alt="2025-10-25-164005_842x280_scrot" src="https://github.com/user-attachments/assets/e5400aaf-03bd-4461-b905-054aa82ca60f" />
My objective is to target all of the cycles in `eval_to_const_value_raw` that are not part of `mir_built`, because if you look at the `mir_built` for a trivial const, we already have the value available.
In this PR, the definition of a trivial const is this:
```rust
const A: usize = 0;
```
Specifically, we look for if the `mir_built` body is a single basic block containing one assign statement and a return terminator, where the assign statement assigns an `Operand::Constant(Const::Val)`. The MIR dumps for these look like:
```
const A: usize = {
let mut _0: usize;
bb0: {
_0 = const 0_usize;
return;
}
}
```
The implementation is built around a new query, `trivial_const(LocalDefId) -> Option<(ConstValue, Ty)>` which returns the contents of the `Const::Val` in the `mir_built` if the `LocalDefId` is a trivial const.
Then I added _debug_ assertions to the beginning of `mir_for_ctfe` and `mir_promoted` to prevent trying to get the body of a trivial const, because that would defeat the optimization here. But these are deliberately _debug_ assertions because the consequence of failing the assertion is that compilation is slow, not corrupt. If we made these hard assertions, I'm sure there are obscure scenarios people will run into where the compiler would ICE instead of continuing on compilation, just a bit slower. I'd like to know about those, but I do not think serving up an ICE is worth it.
With the assertions in place, I just added logic around all the places they were hit, to skip over trying to analyze the bodies of trivial consts.
In the future, I'd like to see this work extended by:
* Pushing detection of trivial consts before MIR building
* Including DefKind::Static and DefKind::InlineConst
* Including consts like `_1 = const 0_usize; _0 = &_1`, which would make a lot of promoteds into trivial consts
* Handling less-trivial consts like `const A: usize = B`, which have `Operand::Constant(Const::Unevaluated)`
Mark desugared range expression spans with DesugaringKind::RangeExpr
This is a prerequisite to removing `QPath::LangItem` (rust-lang/rust#115178) because otherwise there would be no way to detect a range expression in the HIR.
There are some non-obvious Clippy changes so a Clippy team review would be good.
Deduce captures(none) for a return place and parameters
Extend attribute deduction to determine whether parameters using
indirect pass mode might have their address captured. Similarly to
the deduction of `readonly` attribute this information facilitates
memcpy optimizations.
Improve the ICE message for invalid nullary intrinsic calls
In https://github.com/rust-lang/rust/issues/148104, we found the panic message here rather confusing, and (if I'm reading the tea leaves right) that's because the intended audience for either side of the phrase is very different. I think this is more clear if/when this is encountered by users.
I expect this ICE to be hit in practice by people calling the `size_of` and `align_of` intrinsics, so it's now _kind of_ helpful for those users too.
The original effort to stop backends from needing to support nullary intrinsics added a note to all these const-only intrinsics, but when https://github.com/rust-lang/rust/pull/147793 ported two more the paragraph wasn't added. I've added it.
Extend attribute deduction to determine whether parameters using
indirect pass mode might have their address captured. Similarly to
the deduction of `readonly` attribute this information facilitates
memcpy optimizations.
StateTransform: Only load pin field once.
The current implementation starts by transforming all instances of `_1` into `(*_1)`, and then traverses the body again to transform `(*_1)` into `(*(_1.0))`, and again for `Derefer`.
This PR changes the implementation to only traverse the body once. As `_1.0` cannot be not modified inside the body (we just changed its type!), we have no risk of loading from the wrong pointer.
chore: Update to the latest annotate-snippets
This PR updates `annotate-snippets` to the latest version and updates the adapter code[^1] so that `AnnotateSnippetEmitter`'s output matches `HumanEmitter`'s output. If anyone would like to see the differences[^2] between `AnnotateSnippetEmitter` and `HumanEmitter`, [I have a branch](https://github.com/Muscraft/rust/tree/annotate-snippets-default-renderer) where `AnnotateSnippetEmitter` is used in place of `HumanEmitter`.
[^1]: A lot of the adapter code changes are based on code for `HumanEmitter`.
[^2]: Some of the test differences will go away when rust-lang/rust#148001 and rust-lang/rust#148004 are merged.
Improvements to attribute suggestions
Changes in commit 1:
- Add `AcceptContext::suggestions`, which retrieves the suggestions for the currently parsing attribute
- This happens to fix a bug in the way `#[macro_export`]. Closes https://github.com/rust-lang/rust/pull/147987
Changes in commit 2:
- Add a check to the suggestions function so the suggestions for attributes in cfg_attr are nicer. Fixes https://github.com/rust-lang/rust/issues/147693
This is also part (but not all) of the changes needed to unblock https://github.com/rust-lang/rust/pull/147945
r? `@jdonszelmann`
Stop passing resolver disambiguator state to AST lowering.
AST->HIR lowering can use a disjoint set of `DefPathData` as the resolver, so we don't need to pass the disambiguator state.
r? `@oli-obk`
hir_analysis: add missing sizedness bounds
Depends on rust-lang/rust#144064
Default sizedness bounds were not being added to `explicit_super_predicates_of` and `explicit_implied_predicates_of` which meant that a trait bound added to a associated type projection would be missing the implied predicate of the default sizedness supertrait of that trait.
An unexpected consequence of this change was that the check for multiple principals was now finding an additional `MetaSized` principal when eagerly expanding trait aliases - which is fixed by skipping `MetaSized` when elaborating trait aliases in lowering `dyn TraitAlias`.
fix panic when rustc tries to reduce intermediate filenames len with utf8
The issue cannot be reproduced with the former testcase of creating external crates because rust refuses to use "external crate 28_找出字符串中第一个匹配项的下标" because it is not a valid indentifier (starts with number, and contain non ascii chars)
But still using 28_找出字符串中第一个匹配项的下标.rs as a filename is accepted by previous rustc releases So we consider it valid, and add an integration test for it to catch any regression on other code related to non ascii filenames.
Fixrust-lang/rust#147975
Default sizedness bounds were not being added to
`explicit_super_predicates_of` and `explicit_implied_predicates_of`
which meant that a trait bound added to a associated type projection
would be missing the implied predicate of the default sizedness
supertrait of that trait.
An unexpected consequence of this change was that the check for multiple
principals was now finding an additional `MetaSized` principal when
eagerly expanding trait aliases. Instead of special-casing trait aliases
as different from traits and not adding a `MetaSized` supertrait to trait
aliases, filter out `MetaSized` when lowering `dyn Trait`.
The issue cannot be reproduced with the former testcase of creating external crates because
rust refuses to use "external crate 28_找出字符串中第一个匹配项的下标"
because it is not a valid indentifier (starts with number, and contain non ascii chars)
But still using 28_找出字符串中第一个匹配项的下标.rs as a filename is accepted by previous rustc releases
So we consider it valid, and add an integration test for it to catch any regression on other code related to non ascii filenames.
rustc_codegen_llvm: adapt for LLVM 22 change to pass masked intrinsic alignment as an attribute
This was a bit more invasive than I had kind of hoped. An alternate approach would be to add an extra call_intrinsic_with_attrs() that would have the new-in-this-change signature for call_intrinsic, but this felt about equivalent and made it a little easier to audit the relevant callsites of call_intrinsic().
Related LLVM change is llvm/llvm-project#163802.
`@rustbot` label llvm-main
