citool: Always print a signed percentage in job duration changes
I found myself confused by these percentage deltas, because it's not immediately obvious whether a change of 110% means “a little bit worse” (+10%, 110% overall) or ”more than twice as long” (+110%, 210% overall). The correct interpretation is “more than twice as long”.
Including a sign for positive percentages should hopefully make it clearer that they are relative to a baseline of ±0%, not a baseline of 100%.
Manually tested with:
```text
cargo run --manifest-path src/ci/citool/Cargo.toml post-merge-report df984edf44c9537a94a6
```
r? Kobzol
Run regression test for #147964 on next solver too
Original regression: rust-lang/rust#147964
Longer-term tracking of issue: rust-lang/rust#148028
For now, this just makes sure that whatever tests we keep are working the same under both the current solver and the next solver, until we decide what to do with them.
Move rustdoc tests to appropriate subdirectories
## Summary
This PR reorganizes rustdoc tests into their correct subdirectories for better categorization and maintainability.
## Changes
- Moved 6 lint-related tests to `tests/rustdoc-ui/lints/`
- Moved 2 intra-doc link tests to `tests/rustdoc-ui/intra-doc/`
- Moved 3 deref-related tests to `tests/rustdoc-ui/deref/`
- Moved 1 doc-cfg test to `tests/rustdoc/doc-cfg/`
## Tests
All moved tests have been verified and pass in their new locations.
bootstrap: `ensure(doc::Std)` no longer opens a browser
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.
Skip parameter attribute deduction for MIR with `spread_arg`
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.
Contract variable declarations
This change adds contract variables that can be declared in the `requires` clause and can be referenced both in `requires` and `ensures`, subject to usual borrow checking rules. This allows any setup common to both the `requires` and `ensures` clauses to only be done once.
In particular, one future use case would be for [Fulminate](https://dl.acm.org/doi/10.1145/3704879)-like ownership assertions in contracts, that are essentially side-effects, and executing them twice would alter the semantics of the contract.
As of this change, `requires` can now be an arbitrary sequence of statements, with the final expression being of type `bool`. They are executed in sequence as expected, before checking if the final `bool` expression holds.
This PR depends on rust-lang/rust#144438 (which has now been merged).
Contracts tracking issue: https://github.com/rust-lang/rust/issues/128044
**Other changes introduced**:
- Contract macros now wrap the content in braces to produce blocks, meaning there's no need to wrap the content in `{}` when using multiple statements. The change is backwards compatible, in that wrapping the content in `{}` still works as before. The macros also now treat `requires` and `ensures` uniformally, meaning the `requires` closure is built inside the parser, as opposed to in the macro.
**Known limiatations**:
- Contracts with variable declarations are subject to the regular borrow checking rules, and the way contracts are currently lowered limits the usefulness of contract variable declarations. Consider the below example:
```rust
#[requires(let init_x = *x; true)]
#[ensures(move |_| *x == 2 * init_x)]
fn double_in_place(x: &mut i32) {
*x *= 2;
}
```
We have used the new variable declarations feature to remember the initial value pointed to by `x`, however, moving `x` into the `ensures` does not pass the borrow checker, meaning the above function contract is illegal. Ideally, something like the above should be expressable in contracts.
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
