Implement RFC 3678: Final trait methods
Tracking: https://github.com/rust-lang/rust/issues/131179
This PR is based on rust-lang/rust#130802, with some minor changes and conflict resolution.
Futhermore, this PR excludes final methods from the vtable of a dyn Trait.
And some excerpt from the original PR description:
> Implements the surface part of https://github.com/rust-lang/rfcs/pull/3678.
>
> I'm using the word "method" in the title, but in the diagnostics and the feature gate I used "associated function", since that's more accurate.
cc @joshtriplett
If late lifetime resolution fails for whatever reason, forward to RBV
the guarantee that an error was emitted - thereby eliminating the need
for a "hack" to suppress subsequent/superfluous error diagnostics.
Revert, but without type const.
Update symbol for feature err, then update suggestion output, and lastly update tests that change because of those.
Update these new tests with the correct syntax, and few existing tests with the new outputs the merge with main added.
Fix for tidyfmt and some errors when manually resolving a merge conflicts.
Update these tests to use update error messages and type const syntax.
Update comments and error message to use new syntax instead of old type_const attribute.
Remove the type_const attribute
update some more tests to use the new syntax.
Update these test cases.
update feature gate test
Change gate logic for `mgca_type_const_syntax` to work also if `min_generic_const_args` is enabled.
Create a new feature gate that checks for the feature before expansion.
Make rustfmt handle the `type const` syntax correctly.
Add a convience method to check if a RhsKind is type const.
Rename `Const` discriminant to `Body` for `ConstItemRhsKind`
Give the `TraitItemKind` flag an enum instead of a simple bool to better describe what the flag is for.
Update formatting for these match statements.
Update clippy test to use type const syntax.
Update test to use type const syntax.
update rustfmt to match ast items.
Update clippy to match ast and hir items.
Few more test cases that used old attribute, instead of 'type const'
Update to match the output from the feature gate checks.
tidyfmt adjustments.
Update the is_type_const, so I can constrain record!(..) in encoder.rs
Update conditional compilation test.
Move the feature gate to after expansion to allow for cfg(...) to work.
Update some more tests to use the new syntax.
Update type const tests in associated-const-bindings to use new syntax.
Don't check based off the attribute, but the item here.
Update some tests outside of the const_generics folder that were using #[type_const]
update the tests in associated consts that use #[type_const] to use type const
Update these mgca tests with the type const syntax.
Add a flag to TraitItemKind for detecting type const for now. Maybe later change ItemConstRhs to have optional consts but that touches a lot more lines of code.
Don't need into for these now that it's a query.
Add is_type_const query to handle foreign def ids.
update this test to use type const syntax.
Fix logic here, we only want to lower if there is expression in this case.
Update built-in macros to use ConstItemRhsKind
Update more instance of the old ConstItemRhs.
Rename ConstItemKind to ConstItemRhsKind, I noticed there is a typed called ConstantItemKind, so add the Rhs to the name to avoid confusion.
Update lower to use ConstItemKind
Add an other helper method to check if the rhs kinda has an expr.
Update item parse to use ConstItemKind enum.
Felt the field name could a be little clear when editing a few other things.
Change the ConstItem struct see know if we have a type const or regular const.
Make sure this syntax is properly feature gated.
Dont strip const blocks in array lengths
r? oli-obk
mGCA now handles const blocks by *always* handling them during `lower_expr_to_const_arg_direct` instead of *sometimes* stripping them out at parse time. This is just generally a lot clearer/nicer but also means parsing isn't lossy which is just straight up wrong.
We now use `MgcaDisambiguation::Direct` for const blocks because we "directly" represent a const block as `hir::ConstArgKind::Anon` :> The only time that an anon const for const generics uses `MgcaDisambiguation::AnonConst` is for unbraced literals.
Once we properly support literals in `hir::ConstArgKind` (see rust-lang/rust#152139rust-lang/rust#152001) then `MgcaDisambiguation` can be renamed to `AnonConstKind` with `TypeSystem` and `NonTypeSystem` variants. We can also get rid of `mgca_direct_lit_hack`. I expect this to be a very nice cleanup :)
Fixesrust-lang/rustfmt#6788
The diff relating to passing spans around is to avoid a bunch of mGCA diagnostics changing from `const {}` to `{}`. I'm not entirely sure why this was happening.
cc @rust-lang/rustfmt
How do I run the tests in the rustfmt repo from here? `x test rustfmt` only seems to run like 100 tests and doesn't result in a `target/issue-6788.rs` getting created. I've verified locally that this formats correctly though
Mark match arms in try and for as being from desugarings.
Some of the arms created by these desugarings have an expression which isn't marked as coming from the desugaring. e.g. try generates `Continue(val) => val` where the expression has the span of the original parameter (done for diagnostic purposes). Since the arm created just used that span they end up without a desugaring mark unnecessarily.
This is only a minor annoyance with some work I'm doing in clippy.
Stabilize ppc inline assembly
This stabilizes inline assembly for PowerPC and PowerPC64.
Corresponding reference PR: rust-lang/reference#2056
---
From the requirements of stabilization mentioned in https://github.com/rust-lang/rust/issues/93335
> Each architecture needs to be reviewed before stabilization:
> * It must have clobber_abi.
Done in https://github.com/rust-lang/rust/pull/146949.
> * It must be possible to clobber every register that is normally clobbered by a function call.
Done in https://github.com/rust-lang/rust/pull/131341
Similarly, `preserves_flags` is also implemented by this PR. Likewise, there is a non-code change to `preserve_flags` expectations that floating point and vector status and sticky bits are preserved. The reference manual update has more details.
> * Generally review that the exposed register classes make sense.
The followings can be used as input/output:
* reg (`r0`, `r[3-12]`, `r[14-r28]`): Any usable general-purpose register
* reg_nonzero (`r[3-12]`, `r[14-r28]`): General-purpose registers, but excludes `r0`. This is needed for instructions which define `r0` to be the value 0, such as register + immediate memory operations.
* reg/reg_nonzero `r29` on PowerPC64 targets.
* freg (`f[0-31]`): 64 bit floating pointer registers
The following are clobber-only:
* `ctr`, `lr`, `xer`: commonly clobbered special-purpose registers used in inline asm
* `cr` (`cr[0-7]`, `cr`): the condition register fields, or the entire condition register.
* `vreg` (`v[0-31]`): altivec/vmx register
* `vsreg` (`vs[0-63]`): vector-scalar register
* `spe_acc`: SPE accumulator, only available for PowerPC SPE targets.
The vreg and vsreg registers technically accept `#[repr(simd)]` types, but require the experimental `altivec` or `vsx` target features to be enabled. That work seems to be tracked here, rust-lang/rust#42743.
The following cannot be used as operands for inline asm:
* `r2`: the TOC pointer, required for most PIC code.
* `r13`: the TLS pointer
* `r[29]`: Reserved for internal usage by LLVM on PowerPC
* `r[30]`: Reserved for internal usage by LLVM on PowerPC and PowerPC64
* `r31`: the frame pointer
* `vrsave`: this is effectively an unused special-purpose register.
The `preserves_flags` behavior is updated with the following behavior (Note, this is not enforceable today due to LLVM restrictions):
* All status and sticky bits of `fpscr`, `spefscr`, and `vscr` are preserved.
The following registers are unavailable:
* `mma[0-7]`: These are new "registers" available on Power10, they are 512b registers which overlay 4x vsx registers. If needed, users can mark such clobbers as vsN*4, vsN*4+1,...,vsN*4+3.
* `ap`: This is actually a pseudo-register in gcc/llvm.
* `mq`: This register is only available on Power1 and Power2, and is not supported by llvm.
---
cc @taiki-e
r? @Amanieu
@rustbot label +A-inline-assembly
abi: add a rust-preserve-none calling convention
This is the conceptual opposite of the rust-cold calling convention and is particularly useful in combination with the new `explicit_tail_calls` feature.
For relatively tight loops implemented with tail calling (`become`) each of the function with the regular calling convention is still responsible for restoring the initial value of the preserved registers. So it is not unusual to end up with a situation where each step in the tail call loop is spilling and reloading registers, along the lines of:
foo:
push r12
; do things
pop r12
jmp next_step
This adds up quickly, especially when most of the clobberable registers are already used to pass arguments or other uses.
I was thinking of making the name of this ABI a little less LLVM-derived and more like a conceptual inverse of `rust-cold`, but could not come with a great name (`rust-cold` is itself not a great name: cold in what context? from which perspective? is it supposed to mean that the function is rarely called?)
This is the conceptual opposite of the rust-cold calling convention and
is particularly useful in combination with the new `explicit_tail_calls`
feature.
For relatively tight loops implemented with tail calling (`become`) each
of the function with the regular calling convention is still responsible
for restoring the initial value of the preserved registers. So it is not
unusual to end up with a situation where each step in the tail call loop
is spilling and reloading registers, along the lines of:
foo:
push r12
; do things
pop r12
jmp next_step
This adds up quickly, especially when most of the clobberable registers
are already used to pass arguments or other uses.
I was thinking of making the name of this ABI a little less LLVM-derived
and more like a conceptual inverse of `rust-cold`, but could not come
with a great name (`rust-cold` is itself not a great name: cold in what
context? from which perspective? is it supposed to mean that the
function is rarely called?)
mGCA: Support array expression as direct const arguments
tracking issue: rust-lang/rust#132980resolve: rust-lang/rust#150612
Support array expression as direct const arguments (e. g. [1, 2, N]) in min_generic_const_args.
todo:
* [x] Rebase another mGCA PR
* [x] Add more test case
* [x] Modify clippy code
Fix for ICE: eii: fn / macro rules None in find_attr()
Closesrust-lang/rust#149981
This used to ICE:
```rust
macro_rules! foo_impl {}
#[eii]
fn foo_impl() {}
```
`#[eii]` generates a macro (called `foo_impl`) and a default impl. So the partial expansion used to roughly look like the following:
```rust
macro_rules! foo_impl {} // actually resolves here
extern "Rust" {
fn foo_impl();
}
#[eii_extern_target(foo_impl)]
macro foo_impl {
() => {};
}
const _: () = {
#[implements_eii(foo_impl)] // assumed to name resolve to the macro v2 above
fn foo_impl() {}
};
```
Now, shadowing rules for macrov2 and macrov1 are super weird! Take a look at this: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=23f21421921360478b0ec0276711ad36
So instead of resolving to the macrov2, we resolve the macrov1 named the same thing.
A regression test was added to this, and some span_delayed_bugs were added to make sure we catch this in the right places. But that didn't fix the root cause.
To make sure this simply cannot happen again, I made it so that we don't even need to do a name resolution for the default. In other words, the new partial expansion looks more like:
```rust
macro_rules! foo_impl {}
extern "Rust" {
fn foo_impl(); // resolves to here now!!!
}
#[eii_extern_target(foo_impl)]
macro foo_impl {
() => {};
}
const _: () = {
#[implements_eii(known_extern_target=foo_impl)] // still name resolved, but directly to the foreign function.
fn foo_impl() {}
};
```
The reason this helps is that name resolution for non-macros is much more predictable. It's not possible to have two functions like that with the same name in scope.
We used to key externally implementable items off of the defid of the macro, but now the unique identifier is the foreign function's defid which seems much more sane.
Finally, I lied a tiny bit because the above partial expansion doesn't actually work.
```rust
extern "Rust" {
fn foo_impl(); // not to here
}
const _: () = {
#[implements_eii(known_extern_target=foo_impl)] // actually resolves to this function itself
fn foo_impl() {} // <--- so to here
};
```
So the last few commits change the expansion to actually be this:
```rust
macro_rules! foo_impl {}
extern "Rust" {
fn foo_impl(); // resolves to here now!!!
}
#[eii_extern_target(foo_impl)]
macro foo_impl {
() => {};
}
const _: () = {
mod dflt { // necessary, otherwise `super` doesn't work
use super::*;
#[implements_eii(known_extern_target=super::foo_impl)] // now resolves to outside the `dflt` module, so the foreign item.
fn foo_impl() {}
}
};
```
I apologize to whoever needs to review this, this is very subtle and I hope this makes it clear enough 😭.
make attrs actually use `Target::GenericParam`
currently attributes lower `GenericParam` -> `Target::Param` this PR fixes this, so that `GenericParam` is lowered to `Target::GenericParam`
r? @JonathanBrouwer
MGCA: Support for tuple constructors
r? BoxyUwU
part of https://github.com/rust-lang/rust/issues/132980fixesrust-lang/rust#136379fixesrust-lang/rust#138132
i tried to keep implementation very minimal and it's very similar to how structs was implemented with small adjustments
this does not make const constructor like None works, just something like Some(n)
todo:
* ~~tests~~
* write a better description (not sure if needed)
* add more comments and FIXMEs from structs code
Make `asm_experimental_arch` work in `allow_internal_unstable` macros
This change makes it possible to use unstable `asm!`, usually requiring `feature(asm_experimental_arch)`, in proc-macros with the `allow_internal_unstable` attribute.
The test was added on a target where `asm!` is unstable: Wasm. However, this affects *any* target with an unstable `asm!` implementation.
Fix ICE by rejecting const blocks in patterns during AST lowering (closes#148138)
This PR fixes the ICE reported in rust-lang/rust#148138.
The root cause is that `const` blocks aren’t allowed in pattern position, but the AST lowering logic still attempted to create `PatExprKind::ConstBlock`, allowing invalid HIR to reach type checking and trigger a `span_bug!`.
Following the discussion in the issue, this patch removes the `ConstBlock` lowering path from `lower_expr_within_pat`. Any `ExprKind::ConstBlock` inside a pattern is now handled consistently with other invalid pattern expressions.
A new UI test is included to ensure the compiler reports a proper error and to prevent regressions.
Closesrust-lang/rust#148138.
This fixes the ICE reported by rejecting `const` blocks in
pattern position during AST lowering.
Previously, `ExprKind::ConstBlock` could reach HIR as `PatExprKind::ConstBlock`,
allowing invalid patterns to be type-checked and triggering an ICE.
This patch removes the lowering path for const blocks in patterns
and emits a proper diagnostic instead.
A new UI test is added to ensure the compiler reports a regular error
and to prevent regressions.
Support recursive delegation
This PR adds support for recursive delegations and is a part of the delegation feature rust-lang/rust#118212.
r? ``@petrochenkov``
Externally implementable items
Supersedes https://github.com/rust-lang/rust/pull/140010
Tracking issue: https://github.com/rust-lang/rust/issues/125418
Getting started:
```rust
#![feature(eii)]
#[eii(eii1)]
pub fn decl1(x: u64)
// body optional (it's the default)
{
println!("default {x}");
}
// in another crate, maybe
#[eii1]
pub fn decl2(x: u64) {
println!("explicit {x}");
}
fn main() {
decl1(4);
}
```
- tiny perf regression, underlying issue makes multiple things in the compiler slow, not just EII, planning to solve those separately.
- No codegen_gcc support, they don't have bindings for weak symbols yet but could
- No windows support yet for weak definitions
This PR merges the implementation of EII for just llvm + not windows, doesn't yet contain like a new panic handler implementation or alloc handler. With this implementation, it would support implementing the panic handler in terms of EII already since it requires no default implementation so no weak symbols
The PR has been open in various forms for about a year now, but I feel that having some implementation merged to build upon
