flush_delayed: add note about stashed diagnostics
r? `@nnethercote`
Is `emit_stashed_diagnostics` the right advice to give? The other option seems to be to call `finish_diagnostics`. That's what I ended up doing (for now) in https://github.com/rust-lang/miri/pull/4702 because it best matches what happens during normal compilation.
Document the `let this = self;` idiom used in MIR building
In `rustc_mir_build` there are a few `Builder` methods that start with `let this = self;`, so that subsequent code can uniformly refer to the builder as `this`, instead of having to choose between `self` at the top level or `this` when nested in closures that need to borrow the builder.
There is some existing documentation of the idiom in `expr_into_dest`:
https://github.com/rust-lang/rust/blob/69d4d5fc0e4db60272aac85ef27ecccef5764f3a/compiler/rustc_mir_build/src/builder/expr/into.rs#L32-L35
But that documentation is brief and hard to find, especially if one is unaware that such documentation even exists.
---
This PR therefore adds a longer explanation of the `let this = self;` idiom in the module documentation for `rustc_mir_build::builder`, and makes that documentation easier to find by adding a searchable tag (“LET_THIS_SELF”) to the documentation and to each occurrence of the idiom.
Tweak Motor OS linker preset, fix `remote-test-server` for Motor OS
Had to tweak linking options in target spec to make it work (see https://github.com/moturus/motor-os/issues/46).
Error if an autodiff user does not set lto=fat
Based on your feedback, I started to provide a nice error message for a lack of `lto=fat`, instead of us forcing it.
In a next step, we should replace `RUSTFLAGS="-Zautodiff=Enable"` with another Cargo.toml setting, as discussed here: https://github.com/rust-lang/rust/issues/147487#issuecomment-3446558644
As another improvement, we should also figure out why rlib builds do not properly obey the fat=lto setting.
```````@bjorn3```````
use funnel shift as fallback impl for rotating shifts
That lets us remove this gnarly implementation from Miri and const-eval.
However, `rotate_left`/`rotate_right` are stable as const fn, so to do this we have to `rustc_allow_const_fn_unstable` a bunch of const trait stuff. Is that a bad idea? Cc `@oli-obk` `@fee1-dead`
Use rustc target metadata for build-manifest target lists
This ensures that as long as the target metadata is updated to reflect the current state (tier 3 vs 1/2, host toolchain support), the manifest will also be updated. This avoids an extremely common 'oops' when we move targets between tiers.
This mostly removes a bunch of tier 3 targets from manifests. I didn't spot check against produced artifacts but given that they are tier 3 it's probably reasonable to leave it as-is and bug reporters can fix the target metadata in rustc (or we can stop producing artifacts).
Follow-up work would ideally lint the artifact list as part of nightly/beta/stable builds as well, but for now this is simple and hopefully removes at common source of extra PRs when modifying targets.
Manifest list delta:
```diff
--- old
+++ new
-host:i686-apple-darwin
-host:mips-unknown-linux-gnu
-host:mips64-unknown-linux-gnuabi64
-host:mips64el-unknown-linux-gnuabi64
-host:mipsel-unknown-linux-gnu
-host:mipsisa32r6-unknown-linux-gnu
-host:mipsisa32r6el-unknown-linux-gnu
-host:mipsisa64r6-unknown-linux-gnuabi64
-host:mipsisa64r6el-unknown-linux-gnuabi64
-target:aarch64-unknown-hermit
-target:aarch64-unknown-managarm-mlibc
-target:aarch64-unknown-redox
-target:amdgcn-amd-amdhsa
-target:arm64e-apple-darwin
-target:arm64e-apple-ios
-target:arm64e-apple-tvos
-target:armebv7r-none-eabi
-target:armebv7r-none-eabihf
-target:armv7s-apple-ios
-target:bpfeb-unknown-none
-target:bpfel-unknown-none
-target:csky-unknown-linux-gnuabiv2
-target:csky-unknown-linux-gnuabiv2hf
-target:i386-apple-ios
-target:i586-unknown-redox
-target:i686-apple-darwin
-target:loongarch32-unknown-none
-target:loongarch32-unknown-none-softfloat
-target:m68k-unknown-linux-gnu
-target:m68k-unknown-none-elf
-target:mips-mti-none-elf
-target:mips-unknown-linux-gnu
-target:mips-unknown-linux-musl
-target:mips64-unknown-linux-gnuabi64
-target:mips64-unknown-linux-muslabi64
-target:mips64el-unknown-linux-gnuabi64
-target:mips64el-unknown-linux-muslabi64
-target:mipsel-mti-none-elf
-target:mipsel-unknown-linux-gnu
-target:mipsel-unknown-linux-musl
-target:mipsisa32r6-unknown-linux-gnu
-target:mipsisa32r6el-unknown-linux-gnu
-target:mipsisa64r6-unknown-linux-gnuabi64
-target:mipsisa64r6el-unknown-linux-gnuabi64
-target:riscv32gc-unknown-linux-gnu
-target:riscv32im-risc0-zkvm-elf
-target:riscv32ima-unknown-none-elf
-target:riscv64gc-unknown-hermit
-target:riscv64gc-unknown-linux-musl
-target:riscv64gc-unknown-managarm-mlibc
-target:sparc-unknown-none-elf
-target:x86_64-unikraft-linux-musl
-target:x86_64-unknown-hermit
-target:x86_64-unknown-managarm-mlibc
```
This ensures that as long as the target metadata is updated to reflect
the current state (tier 3 vs 1/2, host toolchain support), the manifest
will also be updated. This avoids an extremely common 'oops' when we
move targets between tiers.
This mostly removes a bunch of tier 3 targets from manifests. I didn't
spot check against produced artifacts but given that they are tier 3
it's probably reasonable to leave it as-is and bug reporters can fix the
target metadata in rustc (or we can stop producing artifacts).
Follow-up work would ideally lint the artifact list as part of
nightly/beta/stable builds as well, but for now this is simple and
hopefully removes at common source of extra PRs when modifying targets.
fix(span): track unnormalized source len for dep-info
Add `unnormalized_source_len` field to track the byte length
of source files before normalization (the original length).
`unnormalized_source_len` is for writing the correct file length
to dep-info for `-Zchecksum-hash-algorithm`
Fixes https://github.com/rust-lang/rust/issues/148934
Add `unnormalized_source_len` field to track the byte length
of source files before normalization (the original length).
`unnormalized_source_len` is for writing the correct file length
to dep-info for `-Zchecksum-hash-algorithm`
compute temporary scopes when building MIR, not THIR
This accomplishes two things:
- Makes the THIR slightly smaller by not attaching a full `TempLifetime` to every expression.
- Reduces the number of traversals of the `ScopeTree` by only calling `ScopeTree::temporary_scope` when building MIR for something that needs to be dropped in a temporary scope.
error when ABI does not support guaranteed tail calls
Some ABIs cannot support guaranteed tail calls. There isn't really an exhaustive list, so this is a best effort. Conveniently, we already disallow calling most of these directly anyway. The only exception that I was able to trigger an LLVM assertion with so far was `cmse-nonsecure-entry`.
For that calling convention, LLVM specifically notes that (guaranteed) tail calls cannot be supported:
https://github.com/llvm/llvm-project/blob/28dbbba6c3a4e026e085c48cc022cb97b5d8bc6d/llvm/lib/Target/ARM/ARMISelLowering.cpp#L2331-L2335
---
I have some doubts about the implementation here though. I think it would be nicer to use `CanonAbi`, and move the `become` ABI check into `rustc_hir_typeck`, similar to `check_call_abi`:
https://github.com/rust-lang/rust/blob/d6deffe2debecc66501e50f9573214139ab4d678/compiler/rustc_hir_typeck/src/callee.rs#L157-L194
Both the check for whether an ABI is callable and whether it supports guaranteed tail calls can then be methods (containing exhaustive matches) on `CanonAbi`. I'm however not sure
- if the ABI checks are deliberately only performed when constructing MIR
- what assumptions can be made about the `call` expression in [`check_expr_become`](https://github.com/rust-lang/rust/blob/d6deffe2debecc66501e50f9573214139ab4d678/compiler/rustc_hir_typeck/src/expr.rs#L1126-L1150), it looks like currently the check that the "argument" to `become` is a function call also only occurs later during MIR construction
Are there issues with validating the ABI earlier in `rustc_hir_typeck` that I'm overlooking? I believe that we should already know the call's ABI and whether it is c-variadic at that point.
cc ````@workingjubilee```` for `CanonAbi`, ````@davidtwco```` for cmse
r? ````@WaffleLapkin````
coverage: Associate hole spans with expansion tree nodes
This PR is another incremental step towards expansion region support in coverage instrumentation.
When preparing coverage mappings for a function, we extract “raw” spans from MIR, and then use “hole” spans extracted from HIR to avoid overlap with nested items and closures. That hole-carving process was historically built around the assumption that there would be one set of spans and holes per function, but expansion region support will need to invalidate that assumption.
Therefore, to be more friendly to future work on expansion regions, this PR associates each hole span with its corresponding node in the expansion tree, and makes the span refinement step obtain holes from the current node.
There should be no change to compiler output.
rustc_codegen_llvm: Require `opt-level >= 1` for index-based write_operand_repeatedly() loop
To make debugger stepping intuitive with `-Copt-level=0`. See the adjusted `basic-stepping.rs` test.
This is kind of a revert of **bd0aae92dc76d9 (cg_llvm: use index-based loop in write_operand_repeatedly)**, except we don't revert it, we just make it conditional on `opt-level`. That commit regressed `basic-stepping.rs`, but it was not noticed since that test did not exist back then (it was added later in rust-lang/rust#144876). I have retroactively bisected to find that out.
It seems messy to sprinkle if-cases inside of
`write_operand_repeatedly()` so make the whole function conditional.
The test that bd0aae92dc added in
`tests/codegen/issues/issue-111603.rs` already use `-Copt-level=3`, so we don't need to adjust the compiler flags for it to keep passing.
This PR takes us one step closer to fixing rust-lang/rust#33013.
CC rust-lang/rust#147426 which is related (there will be trivial conflicts for me to resolve in basic-stepping.rs once one of them lands)
To make debugger stepping intuitive with `-Copt-level=0`. See the
adjusted `basic-stepping.rs` test.
This is kind of a revert of bd0aae92dc, except we don't revert it,
we just make it conditional on `opt-level`. That commit regressed
`basic-stepping.rs`, but it was not noticed since that test did not
exist back then. I have retroactively bisected to find that out.
It seems messy to sprinkle if-cases inside of the
`write_operand_repeatedly()` so make the whole function conditional.
The test that bd0aae92dc added in
`tests/codegen/issues/issue-111603.rs` already use `-Copt-level=3`, so
we don't need to adjust the compiler flags for it to keep passing.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#147701 (rustdoc: don't ignore path distance for doc aliases)
- rust-lang/rust#148735 (Fix ICE caused by invalid spans for shrink_file)
- rust-lang/rust#148839 (fix rtsan_nonblocking_async lint closure ICE)
- rust-lang/rust#148846 (add a test for combining RPIT with explicit tail calls)
- rust-lang/rust#148872 (fix: Do not ICE when missing match arm with ill-formed subty is met)
- rust-lang/rust#148880 (Remove explicit install of `eslint` inside of `tidy`'s Dockerfile)
- rust-lang/rust#148883 (bootstrap: dont require cmake if local-rebuild is enabled)
r? `@ghost`
`@rustbot` modify labels: rollup
fix: Do not ICE when missing match arm with ill-formed subty is met
Fixesrust-lang/rust#148192
The ICE comes from the following line, calling `normalize_erasing_regions` to a projection type whose trait bound is not met:
https://github.com/rust-lang/rust/blob/2fcbda6c1a70606bdb09857e01d01fc6229da712/compiler/rustc_pattern_analysis/src/rustc.rs#L185-L194
The above function is called while trying to lint missing match arms, or scrutinize ctors of missing(not necessary error) match arms.
So, the following code can trigger ICEs.
```rust
trait WhereTrait {
type Type;
}
fn foo(e: Enum) {
match e {
Enum::Map(_) => (), // ICE, while trying to lint missing arms
}
if let Enum::Map(_) = e {} // ICE, while trying to scrutinize missing ctors (even worse)
}
enum Enum {
Map(()),
Map2(<() as WhereTrait>::Type),
}
```
This ICE won't be triggered with the following code, as this is filtered out before `check_match` as the existence of ill-formed type inside the variant marks the body as tainted by error in `hir_typeck`, but for the above code, the `hir_typeck` complains nothing because everything it sees is locally correct.
```rust
fn foo(e: Enum) {
match e {
Enum::Map2(_) => (), // No ICE
}
}
```
I've considered visiting and wf checking for the match scrutinee before entering `check_match`, but that might regress the perf and I think just emitting delayed bug would enough as the normalization failure would be originated by other errors like ill-formdness.
Fix ICE caused by invalid spans for shrink_file
Fixesrust-lang/rust#148732
There are two issues in this function:
1. the original issue is caused by a typo error, which is fixed in the first commit
2. another different ice(Patch span `7..7` is beyond the end of buffer `0`) will be reported after fixing the first one, is caused by spans cross file boundaries due to macro expansion. It is fixed in the second commit.
r? `@nnethercote`
edited: also fixesrust-lang/rust#148684, added a new testcase for it in the last commit.
bors