Rollup of 9 pull requests
Successful merges:
- #109102 (Erase escaping late-bound regions when probing for ambiguous associated types)
- #109200 (Fix index out of bounds in `suggest_trait_fn_ty_for_impl_fn_infer`)
- #109211 (E0206 - update description )
- #109222 (Do not ICE for unexpected lifetime with ConstGeneric rib)
- #109235 (fallback to lstat when stat fails on Windows)
- #109248 (Pass the right HIR back from `get_fn_decl`)
- #109251 (Suggest surrounding the macro with `{}` to interpret as a statement)
- #109256 (Check for llvm-tools before install)
- #109257 (resolve: Improve debug impls for `NameBinding`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
resolve: Improve debug impls for `NameBinding`
Print at least the Some/None/Ok/Err status of the nested bindings if not the bindings themselves.
Noticed while reviewing https://github.com/rust-lang/rust/pull/108729.
Pass the right HIR back from `get_fn_decl`
Fixes#109232
Makes sure that the `fn_id: HirId` that we pass to `suggest_missing_return_type` matches up with the `fn_decl: hir::FnDecl` that we pass to it, so the late-bound vars that we fetch from the former match up with the types in the latter...
This HIR suggestion code really needs a big refactor. I've tried to do it in the past (a couple of attempts), but it's a super tangled mess. It really shouldn't be passing around things like `hir::Node` and just deal with `LocalDefId`s everywhere... Anyways, I'd rather fix this ICE, now.
Do not ICE for unexpected lifetime with ConstGeneric rib
Fixes#109143
r? ````@petrochenkov````
Combining this test with the previous test will affect the previous diagnostics, so I added a separate test case.
- only borrow the refcell once per loop
- avoid complex matches to reduce branch paths in the hot loop
- use a by-ref fast path that avoids mutations at the expense of having false negatives
Use index based drop loop for slices and arrays
Instead of building two kinds of drop pair loops, of which only one will be eventually used at runtime in a given monomorphization, always use index based loop.
Fix invalid markdown link references
Fixes invalid link references in librustdoc's template documentation.
`[text](link)` was interpreted as a relative path to the file, making the link invalid, while `[text][label]` references a label defined in the file itself: <https://www.markdownguide.org/basic-syntax/#reference-style-links>
Install projection from RPITIT to default trait method opaque correctly
1. For new lowering strategy `-Zlower-impl-trait-in-trait-to-assoc-ty`, install the correct default trait method projection predicates (RPITIT -> opaque). This makes default trait body tests pass!
2. Fix two WF-checking bugs -- first, we want to make sure that we're always looking for an opaque type in `check_return_position_impl_trait_in_trait_bounds`. That's because the RPITIT projections are normalized to opaques during wfcheck. Second, fix RPITIT's param-envs by not adding the projection predicates that we install on trait methods to make default RPITITs work -- I left a comment why.
3. Also, just a small drive-by for `rustc_on_unimplemented`. Not sure if it affects any tests, but can't hurt.
r? ````@spastorino,```` based off of #109140
inherit_overflow: adapt pattern to also work with v0 mangling
This test was failing under new-symbol-mangling = true. Adapt pattern to work in both cases.
Related to #106002 from December.
Fix riscv64 fuchsia LLVM target name
Currently, riscv64gc-unknown-fuchsia (added in #108722) sets riscv64*gc*-unknown-fuchsia as the LLVM target.
1716932743/compiler/rustc_target/src/spec/riscv64gc_unknown_fuchsia.rs (L5)
However, riscv64*gc*-\* is not a valid LLVM target and causes the following error.
```console
$ rustc --print cfg --target riscv64gc-unknown-fuchsia
error: could not create LLVM TargetMachine for triple: riscv64gc-unknown-fuchsia: No available targets are compatible with triple "riscv64gc-unknown-fuchsia"
```
As with other RISC-V targets, the LLVM target should use riscv64-\*, not riscv64*gc*-\*.
1716932743/compiler/rustc_target/src/spec/riscv64gc_unknown_freebsd.rs (L5)1716932743/compiler/rustc_target/src/spec/riscv64gc_unknown_linux_gnu.rs (L5)
I confirmed that riscv64-unknown-fuchsia is recognized as a valid LLVM target by using custom targets.
```console
# create a custom target with `"llvm-target": "riscv64-unknown-fuchsia" from no-std riscv64gc target.
$ rustc --print target-spec-json -Z unstable-options --target riscv64gc-unknown-none-elf | grep -v is-builtin | sed 's/"llvm-target".*/"llvm-target": "riscv64-unknown-fuchsia",/' > riscv64gc-unknown-fuchsia.json
$ rustc --print cfg --target riscv64gc-unknown-fuchsia.json
debug_assertions
panic="abort"
target_abi=""
target_arch="riscv64"
target_endian="little"
target_env=""
target_feature="a"
target_feature="c"
target_feature="d"
target_feature="f"
target_feature="m"
...
$ cat riscv64gc-unknown-fuchsia.json
{
"arch": "riscv64",
"code-model": "medium",
"cpu": "generic-rv64",
"data-layout": "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128",
"eh-frame-header": false,
"emit-debug-gdb-scripts": false,
"features": "+m,+a,+f,+d,+c",
"linker": "rust-lld",
"linker-flavor": "ld.lld",
"llvm-abiname": "lp64d",
"llvm-target": "riscv64-unknown-fuchsia",
"max-atomic-width": 64,
"panic-strategy": "abort",
"relocation-model": "static",
"supported-sanitizers": [
"kernel-address"
],
"target-pointer-width": "64"
}
# Check the current master's LLVM target name causes an error
$ sed -i 's/riscv64-unknown-fuchsia/riscv64gc-unknown-fuchsia/' riscv64gc-unknown-fuchsia.json
$ rustc --print cfg --target riscv64gc-unknown-fuchsia.json
error: could not create LLVM TargetMachine for triple: riscv64gc-unknown-fuchsia: No available targets are compatible with triple "riscv64gc-unknown-fuchsia"
```
r? ````@tmandry````
Prevent stable `libtest` from supporting `-Zunstable-options`
Took a while for me to get around to this but seems trivial (unless I'm missing some reason this will break all our tests). Fixes#75526
Basically `libtest` already tries to handle this in 501ad021b9/library/test/src/cli.rs (L310-L318)
But that env var was not passed. I'm guessing at one point [this code](501ad021b9/src/bootstrap/compile.rs (L842-L844)) (or a common ancestor) was used to compile the standard library/libtest, but that is no longer the case (or perhaps it never worked, I don't have time to go digging).
I don't love that this is a "allow unstable by default" situation, as it means things like [`rustc-build-sysroot`](https://github.com/RalfJung/rustc-build-sysroot) could accidentally get unstable (CC ````@RalfJung)```` even if this is fixed here, but it's consistent with what happens in `rustc_feature`, so... yeah.
This is user-facing after all, even if it's hard to imagine the outcome of that conversation being "lets continue allowing use of `-Zunstable-features` from stable rust" (especially since a `RUSTC_BOOTSTRAP=1`-shaped loophole remains)... I think it probably should get a vibe check in the t-libs meeting (and plausibly a relnote along the lines of "hey `cargo test -- -Zunstable-options --some --unstable --stuff=here` used to work on stable, that's been fixed, sorry").
I'll nominate it for that after CI comes up green (I've done a smoke check but don't know what (if anything) will need `bootstrap` to enable `RUSTC_BOOTSTRAP=1` when running tests)
r? ````@jyn514````
Remove box expressions from HIR
After #108516, `#[rustc_box]` is used at HIR->THIR lowering and this is no longer emitted, so it can be removed.
This is based on top of #108471 to help with conflicts, so 43490488ccacd1a822e9c621f5ed6fca99959a0b is the only relevant commit (sorry for all the duplicated pings!)
````@rustbot```` label +S-blocked
Wrap the whole LocalInfo in ClearCrossCrate.
MIR contains a lot of information about locals. The primary purpose of this information is the quality of borrowck diagnostics.
This PR aims to drop this information after MIR analyses are finished, ie. starting from post-cleanup runtime MIR.
Tree borrows
This PR implements the experimental Tree Borrows (TB) rules for tracking reference aliasing, as an optional alternative to Stacked Borrows (SB).
SB and TB are mutually exclusive. Using `-Zmiri-tree-borrows` replaces every invocation of SB with the equivalent TB procedure.
A detailed explanation of the TB rules is currently under review, you can find the latest version [here [work in progress]](https://github.com/Vanille-N/tree-borrows/blob/master/model/treebor.pdf).
This PR does NOT yet include
- enough `fail` tests for TB (although TB is less reliant than SB on `fail` tests to check that the implementation matches the design due to `pass` tests being more strict)
- good diagnostics for TB violations
