`final` methods should work the same as without it (if it works without it)

[mu001999]

Tracking: #131179

Found when trying to use final to impl Error::type_id in #153598, this code (play) doesn't work as expected:

#![feature(final_associated_functions)]

trait Tr
where
    Self: 'static,
{
    final fn foo(&self) -> std::any::TypeId {
        std::any::TypeId::of::<Self>()
    }
}

struct Foo;
impl Tr for Foo {}

struct Bar;
impl Tr for Bar {}

fn foo(t: &dyn Tr) -> std::any::TypeId {
    t.foo()
}

fn main() {
    assert_ne!(foo(&Foo), foo(&Bar));
}

I expected to see this happen: run successfully

Instead, this happened: assertion failed. And without final, this will run as expected.

Meta

Build using the Nightly version: 1.96.0-nightly

(2026-03-09 2d76d9bc76f27b03b489)

[mu001999]

@rusbot label +F-final_associated_functions

[eggyal]

@rustbot label +A-dyn-trait +F-final_associated_functions +I-unsound +T-types -needs-triage

[eggyal]

I guess this issue shows that the following statement from the Future Possibilities section of RFC 3678 is incorrect:

final methods do not need to appear in a trait’s vtable.

I'm not sure whether that is the current implementation, and therefore responsible for this issue.

[eggyal]

Ah, yes, we are:

rust/compiler/rustc_trait_selection/src/traits/vtable.rs

Lines 213 to 216 in 3bc6ea5

	// Final methods should not be included in the vtable.
	if trait_method.defaultness(tcx).is_final() {
	return None;
	}

[mu001999]

I'm not sure whether that is the current implementation, and therefore responsible for this issue.

Current implementation will exclude final methods from the trait's vtable (not just do not need).

This should be fixed if we keep dyn-compatible final methods in the vtable and only exclude final methods which are not dyn-compatible. But I think this way will also lead to unpredictable behavior when calling a final method.

[eggyal]

I think, at least for the time being, all final methods should appear in the vtable. Whilst removing them has the runtime benefit of calls through a dyn Trait being direct vs indirect, I suspect the small benefit from such optimisation will be outweighed by the not insignificant effort involved in correctly determining whether a final method is common across implementors or not (with unsoundness if incorrect).

If it's nevertheless decided to only retain in vtables those final methods that do actually depend upon/differ by the implementing type, perhaps in MIR there should be a distinction between the two cases? Wouldn't that avoid calling behaviour being unpredictable (at least according to MIR), and push the unsoundness risk onto correctly lowering from HIR?

That said, I guess lowering to the correct case would require type checking the body - which could lead to cycles...?

[mu001999]

@rustbot claim