Accept trivial consts based on trivial consts
This is an expansion of https://github.com/rust-lang/rust/pull/148040.
The previous implementation only accepted trivial consts that assign a literal. For example:
```rust
const A: usize = 0;
const B: usize = A;
```
Before this PR, only `A` was a trivial const. Now `B` is too.
When a MIR argument is spread at ABI level, deduced attributes are
potentially misapplied, since a spread argument can correspond to zero
or more arguments at ABI level.
Disable deduction for MIR using spread argument for the time being.
In general, the rationale for `--open` is to only open HTML files if
they were "explicitly" invoked from the CLI (e.g. `x doc --open
library/core`). The existing logic did not do that. Instead it opened
the docs unconditionally when a subset of the crates was requested. This
is unfortunate for other Steps in bootstrap, which may wish to `ensure()`
the standard library docs without opening them.
Change `Std` to check if it was explicitly invoked, rather than assuming
it's the case.
rustdoc: remove `--emit=unversioned-shared-resources`
This option hasn't done anything for a long time, and can be removed. I've kept a shim in place to avoid breaking docs.rs, but the option no longer does anything.
Using git-blame, I tracked this option down to
f77ebd4ffa, the commit that introduced EmitType in the first place. It was used with SharedResource::Unversioned, which no longer exists since f9e1f6ffdf removed them.
CC https://github.com/rust-lang/rust/pull/146220
Part of https://github.com/rust-lang/rust/issues/83784
Allow codegen backends to indicate which crate types they support
This way cargo will drop the unsupported crate types for crates that
specify multiple crate types.
This is a prerequisite for https://github.com/rust-lang/miri/pull/4648.
Emit delayed bug during wfck for stranded opaque
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/235
## Problem
The fundamental issue here is ``OpaqueTypeCollector`` operates on ``rustc_middle::Ty``, but ``check_type_wf`` operates on HIR.
Since [check_type_wf](2f7620a5cc/compiler/rustc_hir_analysis/src/check/wfcheck.rs (L2262)) operates on HIR, it can see the stranded opaque and tries to infer it's hidden type. But ``OpaqueTypeCollector`` operates on ``rustc_middle::Ty``, so the ``OpaqueTypeCollector`` can no longer see a stranded opaque, hence its hidden type could not be inferred.
As a result, the tests ICE'ed at 34a8c7368c/compiler/rustc_hir_analysis/src/collect/type_of/opaque.rs (L253)
## Proposed solution
This PR detects stranded opaque types during wf check and emit a delayed bug for it.
## Alternative solution
`@BoxyUwU` and I had considered rewriting ``OpaqueTypeCollector`` to be a HIR visitor instead of a ``rustc_middle::Ty`` visitor, but we believe a HIR-based ``OpaqueTypeCollector`` will not work and might not worth the cost of rewriting.
## Acknowledgement
This PR is a joint effort with `@BoxyUwU` :3
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).
ci: loongarch64: use medium code model to avoid relocation overflows
The LoongArch C/C++ cross toolchain defaults to the `normal` code model, which can cause relocation overflows when linking LLVM after upgrading to verion 22. This change uses the `medium`code model for `loongarch64-linux-gnu` and `loongarch64-linux-musl` builds to avoid these linking errors.
compiletest: show output in debug logging
I had a test I was confused by; the root issue is that `error-pattern` runs before normalization, even though `//~ ERROR` runs after normalization. This logging caught the issue immediately.
1.91.0 release notes
This imports https://github.com/rust-lang/rust/issues/147010 into a PR in preparation for the release next week. It also imports a subset of the Cargo release notes (cc ```@rust-lang/cargo).```
r? ```@rust-lang/release```
```@triagebot``` ping relnotes-interest-group
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
This option hasn't done anything for a long time, and can be
removed. I've kept a shim in place to avoid breaking docs.rs,
but the option no longer does anything.
Using git-blame, I tracked this option down to
f77ebd4ffa, the commit that
introduced EmitType in the first place. It was used with
SharedResource::Unversioned, which no longer exists since
f9e1f6ffdf removed them.
CC https://github.com/rust-lang/rust/pull/146220
Part of https://github.com/rust-lang/rust/issues/83784
