add assembly test for infinite recursion with `become`
tracking issue: https://github.com/rust-lang/rust/issues/112788
fixes https://github.com/rust-lang/rust/issues/125698
Check that infinite recursion via `become` does not grow the stack (even on opt-level 0). The incomplete implementation of `become` did not guarantee that earlier. Although it's unlikely this ever regresses we may as well test it and close the issue.
r? ```@WaffleLapkin```
Expose fmt::Arguments::from_str as unstable.
Now that https://github.com/rust-lang/rust/pull/148789 is merged, we can have a fmt::Arguments::from_str. I don't know if we want to commit to always having an implementation that allows for this, but we can expose it as unstable for now so we can play with it.
Tracking issue: https://github.com/rust-lang/rust/issues/148905
waffle: stop watching codegen ssa
There is a surprising amount of PRs being open to codegen ssa, notification spam makes me stressed. I don't think knowing everything being changed in cg_ssa is useful for me, as most changes are irrelevant to me.
add missing s390x target feature to std detect test
Fix an oversight from https://github.com/rust-lang/rust/pull/145656, where the `is_s390x_feature_detected!` macro and some target features were stabilized, but other target features remain unstable under a new target feature name.
I tested this locally using a `stage1` build on the test file with the `s390x-unknown-linux-gnu` target.
cc ```@uweigand```
r? ```@Amanieu``` (or whoever really)
Disable rustdoc-test-builder test partially for SGX target.
The `rustdoc-test-builder` test started to fail after https://github.com/rust-lang/rust/pull/148608 for SGX target. The reason is, sgx binary can not be executed directly so rustdoc fails to execute passed `--test-builder` binary. This PR simply ignores the success part just like it is ignore for `wasm` target.
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````
CStr docs: Fix CStr vs &CStr confusion
The CStr documentation used to say things about CStr that are only true for &CStr.
Also, it's the bytes that are being borrowed, not the reference. One could say that it's the reference that is doing the borrowing, rather than being borrowed.
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.
Correctly link to associated trait items in reexports
Fixesrust-lang/rust#148008.
Issue was that we didn't add anchors in this case.
r? ``````@lolbinarycat``````
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
bootstrap: dont require cmake if local-rebuild is enabled
This is for people rebuilding stdlib directly from stage 0 with the full toolchain from rust-src rustup component. The toolchain itself should have sufficient LLVM tools, so CMake and LLVM are not required when `build.local-rebuild = true`
Fixesrust-lang/rust#148835
r? Kobzol
Remove explicit install of `eslint` inside of `tidy`'s Dockerfile
`tidy` will already install it (when needed) due to it being in `package.json`
With this change, we don't have the version of `eslint` specific in two different places :)
(this was added in rust-lang/rust#141705 , before `tidy` gained the ability to run `npm install`, and is not needed anymore)
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.
add a test for combining RPIT with explicit tail calls
tracking issue: https://github.com/rust-lang/rust/issues/112788
fixes https://github.com/rust-lang/rust/issues/139305
Combining return position impl trait (RPIT) with guaranteed tail calls does not currently work, but at least it does not ICE any more.
Using RPIT probably should work, see also https://github.com/rust-lang/rust/issues/144953.
The snippet in the issue is not valid for a variety of reasons, and based on the assert that got triggered the ICE was just any `-> impl Trait` at all, so I've made a minimal example using RPIT.
r? `@WaffleLapkin`
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.
Stuart Cook