Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#146593 (Allow specifying multiple bounds for same associated item, except in trait objects)
- rust-lang/rust#147177 ([DebugInfo] Fix MSVC tuple child creation)
- rust-lang/rust#147195 (iter repeat: add tests for new count and last behavior)
- rust-lang/rust#147202 (Swap order of `resolve_coroutine_interiors` and `handle_opaque_type_uses`)
- rust-lang/rust#147204 (Refactor ArrayWindows to use a slice)
- rust-lang/rust#147219 (Add proper error handling for closure in impl)
- rust-lang/rust#147226 (include `outer_inclusive_binder` of pattern types)
- rust-lang/rust#147230 (Fix typo in 'unfulfilled_lint_expectation' to plural)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't create a top-level `true` directory when running UI tests
The funny thing about writing `-Cincremental=true` is that it *does* enable incremental compilation ... using an incremental compilation dir of `./true`.
And for UI tests, that ends up creating a `true` directory in the repository root, which is annoying.
Fortunately, compiletest has an existing `//@ incremental` directive that takes care of creating an empty incremental directory, and passing it to `-Cincremental`.
---
I have manually checked that reverting rust-lang/rust#146649 still causes the updated test to fail.
Remove `no-remap-src-base` from tests
Previously in the `//`-compiletest-directive times, `no-remap-src-base` was implemented as a special `no-*` directive parsing. In the migration from `//` -> `//`@`,` the `// no-remap-src-base` directive was lost, most likely because it had no effect -- the default is not remapping `src-base`.
So remove occurrences of `no-remap-src-base`, as these are not valid directives.
r? `@Zalathar` (since we discussed this on discord, or compiler)
Fix autodiff empty ret regression
closes https://github.com/rust-lang/rust/issues/147144
The two gsoc summer projects caused a bit of churn, which was to be expected, especially since we don't run autodiff in CI yet.
This adds a void return testcase that we should have had anyway, and fixes the regression.
r? `@Zalathar` (Just guessing since I've seen you in a few LLVM PRs and Oli is probably still busy. Feel free to reroll!)
Previously in the `//`-compiletest-directive times, this was implemented
as a special `no-*` directive parsing. In the migration from `//` ->
`//@`, the `// no-remap-src-base` directive was lost, most likely
because it had no effect -- the default is not remapping `src-base`.
So remove occurrences of `no-remap-src-base`, as these are not valid
directives.
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#143069 (Add fast-path for accessing the current thread id)
- rust-lang/rust#146518 (Improve the documentation around `ZERO_AR_DATE`)
- rust-lang/rust#146596 (Add a dummy codegen backend)
- rust-lang/rust#146617 (Don’t suggest foreign `doc(hidden)` types in "the following other types implement trait" diagnostics)
- rust-lang/rust#146635 (cg_llvm: Stop using `as_c_char_ptr` for coverage-related bindings)
- rust-lang/rust#147184 (Fix the bevy implied bounds hack for the next solver)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix the bevy implied bounds hack for the next solver
The diff is trivial, of course, and basically what you already suggested. Mostly dug around a bunch to learn. I hope this is roughly what you had in mind.
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/236.
r? `@lcnr`
Don’t suggest foreign `doc(hidden)` types in "the following other types implement trait" diagnostics
Fixes https://github.com/rust-lang/rust/issues/132024.
``@rustbot`` label A-diagnostics T-compiler
cmse: fix 'region variables should not be hashed'
tracking issue: https://github.com/rust-lang/rust/issues/81391
fixes https://github.com/rust-lang/rust/issues/131639
Some background: the `cmse-nonsecure-call` calling convention is used for a call from "secure" to "non-secure" code. To make sure that "non-secure" cannot read any secrets, restrictions are put on the signatures of functions with this calling convention: they can only use 4 arguments for passing arguments, and one register for passing a result. No arguments are passed via the stack, and all other registers are cleared before the call.
We check during `hir_ty_lowering` that the signature follows these rules. We do that by determining and then inspecting the layout of the type. That works well overall, but can run into asserts when the type itself is ill-formed. This PR fixes one such case.
I believe that the fix here, just erasing the regions, is the right shape, but there may be some nuance that I'm missing.
r? types
Point at fn bound that introduced lifetime obligation
The last note is new
```
error[E0597]: `c` does not live long enough
--> $DIR/without-precise-captures-we-are-powerless.rs:19:20
|
LL | fn simple<'a>(x: &'a i32) {
| -- lifetime `'a` defined here
...
LL | let c = async move || { println!("{}", *x); };
| - binding `c` declared here
LL | outlives::<'a>(c());
| ---------------^---
| | |
| | borrowed value does not live long enough
| argument requires that `c` is borrowed for `'a`
LL | outlives::<'a>(call_once(c));
LL | }
| - `c` dropped here while still borrowed
|
note: requirement that `c` is borrowed for `'a` introduced here
--> $DIR/without-precise-captures-we-are-powerless.rs:7:33
|
LL | fn outlives<'a>(_: impl Sized + 'a) {}
| ^^
```
When encountering a `ConstraintCategory::Predicate` in a funtion call, point at the `Span` for that `Predicate` to explain where the lifetime obligation originates from.
CC rust-lang/rust#55307.
Make replacement suggestion `_` in type verbose
```
error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types
--> $DIR/in-signature.rs:6:21
|
LL | fn arr_fn() -> [u8; _] {
| ^ not allowed in type signatures
|
help: replace with the correct return type
|
LL - fn arr_fn() -> [u8; _] {
LL + fn arr_fn() -> [u8; 3] {
|
```
Skip cleanups on unsupported targets
This commit is an update to the `AbortUnwindingCalls` MIR pass in the compiler. Specifically a new boolean is added for "can this target possibly unwind" and if that's `false` then terminators are all adjusted to be unreachable/not present. The end result is that this fixesrust-lang/rust#140293 for wasm targets.
The motivation for this PR is that currently on WebAssembly targets the usage of the `C-unwind` ABI can lead LLVM to either (a) emit exception-handling instructions or (b) hit a LLVM-ICE-style codegen error. WebAssembly as a base instruction set does not support unwinding at all, and a later proposal to WebAssembly, the exception-handling proposal, was what enabled this. This means that the current intent of WebAssembly targets is that they maintain the baseline of "don't emit exception-handling instructions unless enabled". The commit here is intended to restore this behavior by skipping these instructions even when `C-unwind` is present.
Exception-handling is a relatively tricky and also murky topic in WebAssembly, however. There are two sets of instructions LLVM can emit for WebAssembly exceptions, Rust's Emscripten target supports exceptions, WASI targets do not, the LLVM flags to enable this are not always obvious, and additionally this all touches on "changing exception-handling behavior should be a target-level concern, not a feature". Effectively WebAssembly's exception-handling integration into Rust is not finalized at this time. The best idea at this time is that a parallel set of targets will eventually be added which support exceptions, but it's not clear if/when to do this. In the meantime the goal is to keep existing targets working while still enabling experimentation with exception-handling with `-Zbuild-std` and various permutations of LLVM flags.
To that extent this commit does not blanket disable these landing pads and cleanup routines for WebAssembly but instead checks to see if panic=unwind is enabled or if `+exception-handling` is enabled. Tests are updated here as well to account for this where, by default, using a `C-unwind` ABI won't affect Rust codegen at all. If `+exception-handling` is enabled, however, then Rust codegen will look like native platforms where exceptions are caught and the program aborts. More-or-less I've done my best to keep exceptions working on wasm where it's possible to have them work, but turned them off where they're not supposed to be emitted.
Closesrust-lang/rust#140293
debuginfo: add an unstable flag to write split DWARF to an explicit directory
Bazel requires knowledge of outputs from actions at analysis time, including file or directory name. In order to work around the lack of predictable output name for dwo files, we group the dwo files in a subdirectory of --out-dir as a post-processing step before returning control to bazel. Unfortunately some debugging workflows rely on directly opening the dwo file rather than loading the merged dwp file, and our trick of moving the files breaks those users. We can't just hardlink the file or copy it, because with remote build execution we wouldn't end up with the un-moved file copied back to the developer's workstation. As a fix, we add this unstable flag that causes dwo files to be written to a build-system-controllable location, which then lets bazel hoover up the dwo files, but the objects also have the correct path for the dwo files.
r? `@davidtwco`
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#146653 (improve diagnostics for empty attributes)
- rust-lang/rust#146987 (impl Ord for params and use unstable sort)
- rust-lang/rust#147101 (Use `Iterator::eq` and (dogfood) `eq_by` in compiler and library )
- rust-lang/rust#147123 (Fix removed version numbers of `doc_auto_cfg` and `doc_cfg_hide`)
- rust-lang/rust#147149 (add joboet to library review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
improve diagnostics for empty attributes
Adds a note about them not having any effect. This was previously done for `feature` attributes but no other attributes. In [converting the `feature` parser](https://github.com/rust-lang/rust/pull/146652) I removed that note. This PR adds it back in and makes it so all attributes benefit from it.
Not blocked on rust-lang/rust#146652, either can merge first
tests: Remove ignore-android directive for fixed issue
rust-lang/rust#120567 is marked as fixed, so let's see if we can remove the ignore directives tied to that issue.
<!-- Note to self: wait for https://github.com/rust-lang/team/pull/2002 -->
try-job: arm-android
Fix some crash-test directives
- 120175 fails to crash for non-ELF targets; presumably this wasn't noticed because the CI jobs don't enable rustc assertions for non-ELF hosts.
- 34127, 125722, and 131292 have `only-x86_64`, which is overly specific.
- Unnecessary x86 directives cause friction for contributors using aarch64, especially now that many PR CI jobs also use aarch64.
r? ghost
Detect tuple structs that are unconstructable due to re-export
When a tuple-struct is re-exported that has inaccessible fields at the `use` scope, the type's constructor cannot be accessed through that re-export. We now account for this case and extend the resulting resolution error. We also check if the constructor would be accessible directly, not through the re-export, and if so, we suggest using the full path instead.
```
error[E0423]: cannot initialize a tuple struct which contains private fields
--> $DIR/ctor-not-accessible-due-to-inaccessible-field-in-reexport.rs:12:33
|
LL | let crate::Foo(x) = crate::Foo(42);
| ^^^^^^^^^^
|
note: the type is accessed through this re-export, but the type's constructor is not visible in this import's scope due to private fields
--> $DIR/ctor-not-accessible-due-to-inaccessible-field-in-reexport.rs:3:9
|
LL | pub use my_mod::Foo;
| ^^^^^^^^^^^
help: the type can be constructed directly, because its fields are available from the current scope
|
LL | let crate::Foo(x) = crate::my_mod::Foo(42);
| ~~~~~~~~~~~~~~~~~~
```
Fix#133343.
