Rollup of 9 pull requests
Successful merges:
- #136936 (Use 'yes' instead of 'while-echo' in tests/ui/process/process-sigpipe.rs except 'nto')
- #137026 (Stabilize (and const-stabilize) `integer_sign_cast`)
- #137059 (fix: Alloc new errorcode E0803 for E0495)
- #137177 (Update `minifier-rs` version to `0.3.5`)
- #137210 (compiler: Stop reexporting stuff in cg_llvm::abi)
- #137213 (Remove `rustc_middle::mir::tcx` module.)
- #137216 (eval_outlives: bail out early if both regions are in the same SCC)
- #137228 (Fix typo in hidden internal docs of `TrustedRandomAccess`)
- #137242 (Add reference annotations for the `do_not_recommend` attribute)
r? `@ghost`
`@rustbot` modify labels: rollup
x86: use SSE2 to pass float and SIMD types
This builds on the new X86Sse2 ABI landed in https://github.com/rust-lang/rust/pull/137037 to actually make it a separate ABI from the default x86 ABI, and use SSE2 registers. Specifically, we use it in two ways: to return `f64` values in a register rather than by-ptr, and to pass vectors of size up to 128bit in a register (or, well, whatever LLVM does when passing `<4 x float>` by-val, I don't actually know if this ends up in a register).
Cc `@workingjubilee`
Fixes#133611
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: aarch64-gnu-debug
try-job: test-various
try-job: x86_64-gnu-nopt
try-job: dist-i586-gnu-i586-i686-musl
try-job: x86_64-msvc-1
Add reference annotations for the `do_not_recommend` attribute
This adds reference rule identifiers for the tests of the `diagnostic::do_not_recommend` attribute.
Use 'yes' instead of 'while-echo' in tests/ui/process/process-sigpipe.rs except 'nto'
The `sh` of AIX prints a message about a broken pipe when using the `while-echo` command. It works as expected when using the `yes` command instead. `yes` was originally used in this test but was later replaced with `while-echo` because QNX Neutrino does not have `yes` ([Replace yes command by while-echo in test tests/ui/process/process-sigpipe.rs](https://github.com/rust-lang/rust/pull/109379)). This PR updates the test to use `while-echo` for QNX Neutrino while reverting to `yes` for other platforms.
Pattern Migration 2024: fix incorrect messages/suggestions when errors arise in macro expansions
See the diff between the two commits for how this affected the error message and suggestion. In order to decide how to format those, the pattern migration diagnostic keeps track of which parts of the user's pattern cause problems in Edition 2024. However, it neglected to do some of this bookkeeping when pointing to macro expansion sites. This fixes that.
Do not ICE on default_field_value const with lifetimes
`#![feature(default_field_values)]` uses a `const` body that should be treated as inline `const`s, but is actually being detected otherwise. This is similar to the situation in #78174, so we take the same solution: we check if the const actually comes from a field, and if it does, we use that logic to get the appropriate lifetimes and not ICE during borrowck.
Fix#135649.
Rollup of 7 pull requests
Successful merges:
- #137095 (Replace some u64 hashes with Hash64)
- #137100 (HIR analysis: Remove unnecessary abstraction over list of clauses)
- #137105 (Restrict DerefPure for Cow<T> impl to T = impl Clone, [impl Clone], str.)
- #137120 (Enable `relative-path-include-bytes-132203` rustdoc-ui test on Windows)
- #137125 (Re-add missing empty lines in the releases notes)
- #137145 (use add-core-stubs / minicore for a few more tests)
- #137149 (Remove SSE ABI from i586-pc-windows-msvc)
r? `@ghost`
`@rustbot` modify labels: rollup
use add-core-stubs / minicore for a few more tests
See https://github.com/rust-lang/rust/issues/131485 for context. These are some tests I worked on in the past so I figured I'd see if `minicore` works for them. :)
Fix const items not being allowed to be called `r#move` or `r#static`
Because of an ambiguity with const closures, the parser needs to ensure that for a const item, the `const` keyword isn't followed by a `move` or `static` keyword, as that would indicate a const closure:
```rust
fn main() {
const move // ...
}
```
This check did not take raw identifiers into account, therefore being unable to distinguish between `const move` and `const r#move`. The latter is obviously not a const closure, so it should be allowed as a const item.
This fixes the check in the parser to only treat `const ...` as a const closure if it's followed by the *proper keyword*, and not a raw identifier.
Additionally, this adds a large test that tests for all raw identifiers in all kinds of positions, including `const`, to prevent issues like this one from occurring again.
fixes#137128
Overhaul `rustc_middle::limits`
In particular, to make `pattern_complexity` work more like other limits, which then enables some other simplifications.
r? ``@Nadrieril``
Because of an ambiguity with const closures, the parser needs to ensure
that for a const item, the `const` keyword isn't followed by a `move` or
`static` keyword, as that would indicate a const closure:
```rust
fn main() {
const move // ...
}
```
This check did not take raw identifiers into account, therefore being
unable to distinguish between `const move` and `const r#move`. The
latter is obviously not a const closure, so it should be allowed as a
const item.
This fixes the check in the parser to only treat `const ...` as a const
closure if it's followed by the *proper keyword*, and not a raw
identifier.
Additionally, this adds a large test that tests for all raw identifiers in
all kinds of positions, including `const`, to prevent issues like this
one from occurring again.
Rework `name_regions` to not rely on reverse scc graph for non-member-constrain usages
Fixes https://github.com/rust-lang/rust/issues/137015
Splits the `name_regions` into two versions: One meant for member region constraint error reporting (which I've renamed to `name_regions_for_member_constraint`), and one meant *just* to replace region vids with an external region.
Use the latter in the usage sites I added in #136559, since the regions returned by `name_regions_for_member_constraint` are also not *totally* accurate (which is fine for how they're used for member region constraint error reporting -- they're intentionally returning overapproximated universal regions so that we have something to name in `+ use<'a>` suggestions, because opaques can only capture universal regions and since member region constraints don't insert any edges into the region graph, the error region is probably gonna be shorter than a universal region) and because that function requires the reverse scc graph to have been computed which isn't done for our usages in #136559.
Try to recover from path sep error in type parsing
Fixes#129273
Error using `:` in the argument list may mess up the parser.
case `tests/ui/suggestions/struct-field-type-including-single-colon` also changed, seems it's the same meaning, should be OK.
r? `@estebank`
Do not allow attributes on struct field rest patterns
Fixes#81282.
This removes support for attributes on struct field rest patterns (the `..` bit) from the parser. Previously any attributes were being parsed but dropped from the AST, so didn't work and were deleted by rustfmt.
This needs an equivalent change to the reference but I wanted to see how this PR is received first.
The error message it produces isn't great, however it does match the error you get if you try to add attributes to .. in struct expressions atm, although I can understand wanting to do better given this was previously accepted. I think I could move attribute parsing back up to where it was and then emit a specific new error for this case, however I might need some guidance as this is the first time I've messed around inside the compiler.
While this is technically breaking I don't think it's much of an issue: attributes in this position don't currently do anything and rustfmt outright deletes them, meaning it's incredibly unlikely to affect anyone. I have already made the equivalent change to *add* support for attributes (mostly) but the conversation in the linked issue suggested it would be more reasonable to just remove them (and pointed out it's much easier to add support later if we realise we need them).
Fix crate name validation
Reject macro calls inside attribute `#![crate_name]` like in `#![crate_name = concat!("na", "me")]`.
Prior to #117584, the result of the expansion (here: `"name"`) would actually be properly picked up by the compiler and used as the crate name. However since #117584 / on master, we extract the "value" (i.e., the *literal* string literal) of the `#![crate_name]` much earlier in the pipeline way before macro expansion and **skip**/**ignore** any `#![crate_name]`s "assigned to" a macro call. See also #122001.
T-lang has ruled to reject `#![crate_name = MACRO!(...)]` outright very similar to other built-in attributes whose value we need early like `#![crate_type]`. See accepted FCP: https://github.com/rust-lang/rust/issues/122001#issuecomment-2023203182.
Note that the check as implemented in this PR is even more "aggressive" compared to the one of `#![crate_type]` by running as early as possible in order to reject `#![crate_name = MACRO!(...)]` even in "non-normal" executions of `rustc`, namely on *print requests* (e.g., `--print=crate-name` and `--print=file-names`). If I were to move the validation step a bit further back close to the `#![crate_type]` one, `--print=crate-name` (etc.) would *not* exit fatally with an error in this kind of situation but happily report an incorrect crate name (i.e., the "crate name" as if `#![crate_name]` didn't exist / deduced from other sources like `--crate-name` or the file name) which would match the behavior on master. Again, see also #122001.
I'm mentioning this explicitly because I'm not sure if it was that clear in the FCP'ed issue. I argue that my current approach is the most reasonable one. I know (from reading the code and from past experiments) that various print requests are still quite broken (mostly lack of validation).
To the best of my knowledge, there's no print request whose output references/contains a crate *type*, so there's no "inherent need" to move `#![crate_type]`'s validation to happen earlier.
---
Fixes#122001.
https://github.com/rust-lang/rust/labels/relnotes: Compatibility. Breaking change.
Gets rid of two top-level UI tests which is always great.
Furthermore, move `need-crate-arg-ignore-tidy$x.rs`
from `command/` to `invalid-compile-flags/`.
`command/` concerns `std::process::Command` tests, not CLI tests.
add x86-sse2 (32bit) ABI that requires SSE2 target feature
This is the first commit of https://github.com/rust-lang/rust/pull/135408:
The primary goal of this is to make SSE2 required for our i686 targets (at least for the ones that use Pentium 4 as their baseline), to ensure they cannot be affected by https://github.com/rust-lang/rust/issues/114479. This has been MCPd in https://github.com/rust-lang/compiler-team/issues/808, and is tracked in https://github.com/rust-lang/rust/issues/133611.
We do this by defining a new ABI that these targets select, and making SSE2 required by the ABI (that's the first commit). That's kind of a hack, but it is the easiest way to make a target feature required via the target spec. In a follow-up change (https://github.com/rust-lang/rust/pull/135408), we can actually make use of SSE2 for the ABI, but that is running into some infrastructure issues.
r? `@workingjubilee`
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: aarch64-gnu-debug
try-job: test-various
try-job: x86_64-gnu-nopt
try-job: dist-i586-gnu-i586-i686-musl
Normalize closure instance before eagerly monomorphizing it
We were monomorphizing two versions of the closure (or in the original issue, coroutine) -- one with normalized captures and one with unnormalized captures. This led to a symbol collision.
Fixes#137009
r? `@saethlin` or reassign
Fix presentation of purely "additive" replacement suggestion parts
#127541 changes replacement suggestions to use the "diff" view always, which I think is really verbose in cases where a replacement snippet is a "superset" of the snippet that is being replaced.
Consider:
```
LL - Self::Baz: Clone,
LL + Self::Baz: Clone, T: std::clone::Clone
```
In this code, we suggest replacing `", "` with `", T: std::clone::Clone"`. This is a consequence of how the snippet is constructed. I believe that since the string that is being replaced is a subset of the replacement string, it's not providing much value to present this as a diff. Users should be able to clearly understand what's being suggested here using the `~` underline view we've been suggesting for some time now.
Given that this affects ~100 tests out of the ~1000 UI tests affected, I expect this to be a pretty meaningful improvement of the fallout of #127541.
---
In the last commit, this PR also "trims" replacement parts so that they are turned into their purely additive subset, if possible. See the diff for what this means.
---
r? estebank
Change description from compiletest to regression test
Co-authored-by: 许杰友 Jieyou Xu (Joe) <39484203+jieyouxu@users.noreply.github.com>
Improve test name, location, and description
Update tests/ui/impl-trait/impl-fn-rpit-opaque-107883.rs
Co-authored-by: waffle <waffle.lapkin@gmail.com>
