Rollup of 6 pull requests
Successful merges:
- #127164 (match lowering: Clarify the main loop of the algorithm)
- #127422 (as_simd: fix doc comment to be in line with align_to)
- #127596 (More suggestion for converting `Option<&Vec<T>>` to `Option<&[T]>`)
- #127607 (compiletest: Better error message for bad `normalize-*` headers)
- #127622 (Mark `builtin_syntax` as internal)
- #127625 (Revert accidental comment deletion)
r? `@ghost`
`@rustbot` modify labels: rollup
compiletest: Better error message for bad `normalize-*` headers
Follow-up to #126777.
Example of the new error message in context:
```text
---- [ui] tests/ui/rfcs/rfc-2632-const-trait-impl/effects/minicore.rs stdout ----
thread '[ui] tests/ui/rfcs/rfc-2632-const-trait-impl/effects/minicore.rs' panicked at src/tools/compiletest/src/header.rs:1001:13:
couldn't parse custom normalization rule: `normalize-stderr-test ".*note: .*\n\n" -> ""`
help: expected syntax is: `normalize-stderr-test: "REGEX" -> "REPLACEMENT"`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
as_simd: fix doc comment to be in line with align_to
In #121201, the guarantees about `align_offset` and `align_to` were changed. This PR aims to correct the doc comment of `as_simd` to be in line with the new `align_to`.
Tagging #86656 for good measure.
match lowering: Clarify the main loop of the algorithm
Now that we expand or-patterns in a single place in the algorithm, we can move it (back) to the main part of the loop. This makes the call-graph of the main loop rather simple: `match_candidates` has three branches that each call back to `match_candidates`. The remaining tricky part is `finalize_or_candidate`.
I also factored out the whole "process a prefix of the candidates then process the rest" thing which I think helps legibility.
The first two commits are a fix for an indexing mistake I introduced in https://github.com/rust-lang/rust/pull/126553, already sumitted in https://github.com/rust-lang/rust/pull/127028 but feel free to merge this first.
r? `@matthewjasper`
Rollup of 8 pull requests
Successful merges:
- #124599 (Suggest borrowing on fn argument that is `impl AsRef`)
- #127572 (Don't mark `DEBUG_EVENT` struct as `repr(packed)`)
- #127588 (core: Limit remaining f16 doctests to x86_64 linux)
- #127591 (Make sure that labels are defined after the primary span in diagnostics)
- #127598 (Allows `#[diagnostic::do_not_recommend]` to supress trait impls in suggestions as well)
- #127599 (Rename `lazy_cell_consume` to `lazy_cell_into_inner`)
- #127601 (check is_ident before parse_ident)
- #127605 (Remove extern "wasm" ABI)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove extern "wasm" ABI
Remove the unstable `extern "wasm"` ABI (`wasm_abi` feature tracked in #83788).
As discussed in https://github.com/rust-lang/rust/pull/127513#issuecomment-2220410679 and following, this ABI is a failed experiment that did not end up being used for anything. Keeping support for this ABI in LLVM 19 would require us to switch wasm targets to the `experimental-mv` ABI, which we do not want to do.
It should be noted that `Abi::Wasm` was internally used for two things: The `-Z wasm-c-abi=legacy` ABI that is still used by default on some wasm targets, and the `extern "wasm"` ABI. Despite both being `Abi::Wasm` internally, they were not the same. An explicit `extern "wasm"` additionally enabled the `+multivalue` feature.
I've opted to remove `Abi::Wasm` in this patch entirely, instead of keeping it as an ABI with only internal usage. Both `-Z wasm-c-abi` variants are now treated as part of the normal C ABI, just with different different treatment in
adjust_for_foreign_abi.
Allows `#[diagnostic::do_not_recommend]` to supress trait impls in suggestions as well
This commit changes the error reporting mechanism for not implemented traits to skip impl marked as `#[diagnostic::do_not_recommend]` in the help part of the error message ("the following other types implement trait `Foo`:"). The main use case here is to allow crate authors to skip non-meaningful confusing suggestions. A common example for this are fully generic impls on tuples.
Related to https://github.com/rust-lang/rust/issues/51992
r? `@compiler-errors`
Make sure that labels are defined after the primary span in diagnostics
Putting a `#[label]` before a `#[primary_span]` results in that label being overwritten, due to the semantics of `Diagnostic::span` and the fact that labels are stored in the `MultiSpan` of the diagnostic.
This isn't possible to fix in general, since a lot of code actually *relies* in this overwriting behavior (e.g. `rustc_on_unimplemented`). However, it's useful to enforce this for derive-diagnostics, since this is certainly never what you intend to do in a derived diagnostic, where all the fields are meaningful parts of the diagnostic being rendered.
This only matters for `#[label]`, since those are the ones stored in the `MultiSpan` of the error.
We could also make this "just work" by sorting the attrs or processing the primary span attr first, however I think it's kinda pointless to do.
There was 1 case where this mattered, but we literally didn't have a test exercising that diagnostic 🙃
core: Limit remaining f16 doctests to x86_64 linux
On s390x, every use of the f16 data type will currently ICE due to https://github.com/llvm/llvm-project/issues/50374, causing doctest failures on the platform.
Most doctests were already restricted to certain platforms, so fix this by likewise restricting the remaining five.
Suggest borrowing on fn argument that is `impl AsRef`
When encountering a move conflict, on an expression that is `!Copy` passed as an argument to an `fn` that is `impl AsRef`, suggest borrowing the expression.
```
error[E0382]: use of moved value: `bar`
--> f204.rs:14:15
|
12 | let bar = Bar;
| --- move occurs because `bar` has type `Bar`, which does not implement the `Copy` trait
13 | foo(bar);
| --- value moved here
14 | let baa = bar;
| ^^^ value used here after move
|
help: borrow the value to avoid moving it
|
13 | foo(&bar);
| +
```
Fix#41708
Add `f16` and `f128` as simd types in LLVM
`@sayantn` is working on adding SIMD for `f16` and hitting the `FloatingPointVector` error. This should fix it and unblock adding support for `simd_fma` and `simd_fabs` in stdarch.
Avoid follow-up errors and ICEs after missing lifetime errors on data structures
Tuple struct constructors are functions, so when we call them typeck will use the signature tuple struct constructor function to provide type hints. Since typeck mostly ignores and erases lifetimes, we end up never seeing the error lifetime in writeback, thus not tainting the typeck result.
Now, we eagerly taint typeck results by tainting from `resolve_vars_if_possible`, which is called all over the place.
I did not carry over all the `crashes` test suite tests, as they are really all the same cause (missing or unknown lifetime names in tuple struct definitions or generic arg lists).
fixes#124262fixes#124083fixes#125155fixes#125888fixes#125992fixes#126666fixes#126648fixes#127268fixes#127266fixes#127304
Remove the unstable `extern "wasm"` ABI (`wasm_abi` feature tracked
in #83788).
As discussed in https://github.com/rust-lang/rust/pull/127513#issuecomment-2220410679
and following, this ABI is a failed experiment that did not end
up being used for anything. Keeping support for this ABI in LLVM 19
would require us to switch wasm targets to the `experimental-mv`
ABI, which we do not want to do.
It should be noted that `Abi::Wasm` was internally used for two
things: The `-Z wasm-c-abi=legacy` ABI that is still used by
default on some wasm targets, and the `extern "wasm"` ABI. Despite
both being `Abi::Wasm` internally, they were not the same. An
explicit `extern "wasm"` additionally enabled the `+multivalue`
feature.
I've opted to remove `Abi::Wasm` in this patch entirely, instead
of keeping it as an ABI with only internal usage. Both
`-Z wasm-c-abi` variants are now treated as part of the normal
C ABI, just with different different treatment in
adjust_for_foreign_abi.
Require a colon in `//@ normalize-*:` test headers
The previous parser for `//@ normalize-*` headers (before #126370) was so lax that it did not require `:` after the header name. As a result, the test suite contained a mix of with-colon and without-colon normalize headers, both numbering in the hundreds.
This PR updates the without-colon headers to add a colon (matching the style used by other headers), and then updates the parser to make the colon mandatory.
(Because the normalization parser only runs *after* the header system identifies a normalize header, this will detect and issue an error for relevant headers that lack the colon.)
Addresses one of the points of #126372.
Implement simple, unstable lint to suggest turning closure-of-async-block into async-closure
We want to eventually suggest people to turn `|| async {}` to `async || {}`. This begins doing that. It's a pretty rudimentary lint, but I wanted to get something down so I wouldn't lose the code.
Tracking:
* #62290
This commit changes the error reporting mechanism for not implemented
traits to skip impl marked as `#[diagnostic::do_not_recommend]` in the
help part of the error message ("the following other types implement
trait `Foo`:"). The main use case here is to allow crate authors to skip
non-meaningful confusing suggestions. A common example for this are
fully generic impls on tuples.
Migrate `issue-83112-incr-test-moved-file`, `type-mismatch-same-crate-name` and `issue-109934-lto-debuginfo` `run-make` tests to rmake or ui
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
I have noticed that the new UI test `debuginfo-lto-alloc` is outputting artifacts that aren't getting cleaned up because of its `-C incremental`. That might be the justification needed to keep it as a run-make test?
Try it on:
// try-job: test-various // previously passed
try-job: armhf-gnu
try-job: aarch64-apple
try-job: x86_64-msvc
