Rework pattern and expression nonterminal kinds.
Some tweaks to `NonterminalKind` that will assist with #124141. Details in the individual commits.
r? compiler-errors
cc ```@eholk```
Replace `f16` and `f128` pattern matching stubs with real implementations
This section of code depends on `rustc_apfloat` rather than our internal types, so this is one potential ICE that we should be able to melt now.
r? `@Nadrieril`
This section of code depends on `rustc_apfloat` rather than our internal
types, so this is one potential ICE that we should be able to melt now.
This also fixes some missing range and match handling in `rustc_middle`.
Merge `PatParam`/`PatWithOr`, and `Expr`/`Expr2021`, for a few reasons.
- It's conceptually nice, because the two pattern kinds and the two
expression kinds are very similar.
- With expressions in particular, there are several places where both
expression kinds get the same treatment.
- It removes one unreachable match arm.
- Most importantly, for #124141 I will need to introduce a new type
`MetaVarKind` that is very similar to `NonterminalKind`, but records a
couple of extra fields for expression metavars. It's nicer to have a
single `MetaVarKind::Expr` expression variant to hold those extra
fields instead of duplicating them across two variants
`MetaVarKind::{Expr,Expr2021}`. And then it makes sense for patterns
to be treated the same way, and for `NonterminalKind` to also be
treated the same way.
I also clarified the comments, because I have long found them a little
hard to understand.
Remove use of const traits (and `feature(effects)`) from stdlib
The current uses are already unsound because they are using non-const impls in const contexts. We can reintroduce them by reverting the commit in this PR, after #120639 lands.
Also, make `effects` an incomplete feature.
cc `@rust-lang/project-const-traits`
r? `@compiler-errors`
Fix `...` in multline code-skips in suggestions
When we have long code skips, we write `...` in the line number gutter.
For suggestions, we were "centering" the `...` with the line, but that was inconsistent with what we do in every other case *and* off-center.
Add `f16` inline ASM support for 32-bit ARM
Adds `f16` inline ASM support for 32-bit ARM. SIMD vector types are taken from [here](https://developer.arm.com/architectures/instruction-sets/intrinsics/#f:`@navigationhierarchiesreturnbasetype=[float]&f:@navigationhierarchieselementbitsize=[16]&f:@navigationhierarchiesarchitectures=[A32]).`
Relevant issue: #125398
Tracking issue: #116909
`@rustbot` label +F-f16_and_f128
Add a tidy rule to check that fluent messages and attrs don't end in `.`
This adds a new dependency on `fluent-parse` to `tidy` -- we already rely on it in rustc so I feel like it's not that big of a deal.
This PR also adjusts many error messages that currently end in `.`; not all of them since I added an `ALLOWLIST`, excluded `rustc_codegen_*` ftl files, and `.teach_note` attributes.
r? ``@estebank`` ``@oli-obk``
Add `f16` inline ASM support for RISC-V
This PR adds `f16` inline ASM support for RISC-V. A `FIXME` is left for `f128` support as LLVM does not support the required `Q` (Quad-Precision Floating-Point) extension yet.
Relevant issue: #125398
Tracking issue: #116909
`@rustbot` label +F-f16_and_f128
Rename a bunch of things in the new solver and `rustc_type_ir`
* Renames `interner()` to `cx()` in the solver and `TypeFolder`.
* Renames `Infcx` generic param to `D`
* Moves `infcx.rs` to `delegate.rs`
r? lcnr
Stop sorting `Span`s' `SyntaxContext`, as that is incompatible with incremental
work towards https://github.com/rust-lang/rust/issues/90317
Luckily no one actually needed these to be sorted, so it didn't even affect diagnostics. I'm guessing they'd have been sorted by creation time anyway, so it wouldn't really have mattered.
r? `@cjgillot`
Rollup of 8 pull requests
Successful merges:
- #126125 (Improve conflict marker recovery)
- #126481 (Add `powerpc-unknown-openbsd` maintenance status)
- #126613 (Print the tested value in int_log tests)
- #126617 (Expand `avx512_target_feature` to include VEX variants)
- #126700 (Make edition dependent `:expr` macro fragment act like the edition-dependent `:pat` fragment does)
- #126707 (Pass target to inaccessible-temp-dir rmake test)
- #126767 (`StaticForeignItem` and `StaticItem` are the same)
- #126774 (Fix another assertion failure for some Expect diagnostics.)
r? `@ghost`
`@rustbot` modify labels: rollup
More ptr metadata gvn
There's basically 3 parts to this PR.
1. Allow references as arguments to `UnOp::PtrMetadata`
This is a MIR semantics addition, so
r? mir
Rather than just raw pointers, also allow references to be passed to `PtrMetadata`. That means the length of a slice can be just `PtrMetadata(_1)` instead of also needing a ref-to-pointer statement (`_2 = &raw *_1` + `PtrMetadata(_2)`).
AFAIK there should be no provenance or tagging implications of looking at the *metadata* of a pointer, and the code in the backends actually already supported it (other than a debug assert, given that they don't care about ptr vs reference, really), so we might as well allow it.
2. Simplify the argument to `PtrMetadata` in GVN
Because the specific kind of pointer-like thing isn't that important, GVN can simplify all those details away. Things like `*const`-to-`*mut` casts and `&mut`-to-`&` reborrows are irrelevant, and skipping them lets it see more interesting things.
cc `@cjgillot`
Notably, unsizing casts for arrays. GVN supported that for `Len`, and now it sees it for `PtrMetadata` as well, allowing `PtrMetadata(pointer)` to become a constant if that pointer came from an array-to-slice unsizing, even through a bunch of other possible steps.
3. Replace `NormalizeArrayLen` with GVN
The `NormalizeArrayLen` pass hasn't been running even in optimized builds for well over a year, and it turns out that GVN -- which *is* on in optimized builds -- can do everything it was trying to do.
So the code for the pass is deleted, but the tests are kept, just changed to the different pass.
As part of this, `LowerSliceLen` was changed to emit `PtrMetadata(_1)` instead of `Len(*_1)`, a small step on the road to eventually eliminating `Rvalue::Len`.
Fix another assertion failure for some Expect diagnostics.
Very similar to #126719. So much so that I added a new case to the test from that PR rather than creating a new one.
r? `@oli-obk`
`StaticForeignItem` and `StaticItem` are the same
The struct `StaticItem` and `StaticForeignItem` are the same, so remove `StaticForeignItem`. Having them be separate is unique to `static` items -- unlike `ForeignItemKind::{Fn,TyAlias}`, which use the normal AST item.
r? ``@spastorino`` or ``@oli-obk``
