Don't resolve generic impls that may be shadowed by dyn built-in impls

[compiler-errors]

NOTE: This is a hack. This is not trying to be a general fix for the issue that we've allowed overlapping built-in trait object impls and user-written impls for quite a long time, and traits like Any rely on this (#57893) -- this PR specifically aims to mitigate a new unsoundness that is uncovered by the MIR inliner (#114928) that interacts with this pre-existing issue.

Builtin dyn Trait impls may overlap with user-provided blanket impls (impl<T: ?Sized> Trait for T) in generic contexts. This leads to bugs when instances are resolved in polymorphic contexts, since we typically prefer object candidates over impl candidates.

This PR implements a (hacky) heuristic to resolve_associated_item to account for that unfortunate hole in the type system -- we now bail with ambiguity if we try to resolve a non-rigid instance whose self type is not known to be sized. This makes sure we can still inline instances like impl<T: Sized> Trait for T, which can never overlap with dyn Trait's built-in impl, but we avoid inlining an impl that may be shadowed by a dyn Trait.

Fixes #114928

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[compiler-errors]

This is the problematic inlined line -- when this function is eventually monomorphized for T = dyn Any, we're acquiring the type-id of dyn Any rather than going thru the vtable.

[lcnr]

please move this check to instance resolve instead and add these two tests to make sure that they don't also end up triggering this bug

trait Trait {
    fn foo(&self) {}
}

impl<T: ?Sized> Trait for T {
    fn foo(&self) {
        println!("generic: {}", std::any::type_name::<T>());
    }
}


fn bar<T: ?Sized>() -> fn(&T) {
    Trait::foo
    // If const prop where to propagate the instance
}

fn main() {
    bar::<dyn Trait>()(&1);
}

#![feature(inline_const)]
trait Trait {
    fn foo(&self) {}
}

impl<T: ?Sized> Trait for T {
    fn foo(&self) {
        println!("generic: {}", std::any::type_name::<T>());
    }
}


fn bar<T: ?Sized>() -> fn(&T) {
    const { Trait::foo as fn(&T) }
}

fn main() {
    bar::<dyn Trait>()(&1);
}

[lcnr]

r? @lcnr

[lcnr]

r=me after a types FCP. While this change is not breaking existing code, it is a new special-case of the types system so I think it's a good idea to notify the rest of the types team of this.

[compiler-errors]

@rfcbot fcp merge

See PR description :>

[compiler-errors]

@rfcbot fcp cancel

[rfcbot]

@compiler-errors proposal cancelled.

[compiler-errors]

@rfcbot fcp merge

see PR description :>

[rfcbot]

Team member @compiler-errors has proposed to merge this. The next step is review by the rest of the tagged team members:

• @BoxyUwU
• @aliemjay
• @compiler-errors
• @jackh726
• @lcnr
• @nikomatsakis
• @oli-obk
• @spastorino

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[compiler-errors]

@bors r-

[compiler-errors]

@bors r=lcnr

[bors]

📌 Commit a30ad3a has been approved by lcnr

It is now in the queue for this repository.

[bors]

⌛ Testing commit a30ad3a with merge 39efb1c...

[bors]

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing 39efb1c to master...

[bors]

👀 Test was successful, but fast-forwarding failed: 422 Update is not a fast forward

[oli-obk]

@bors retry

[rust-timer]

Finished benchmarking commit (39efb1c): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	3.2%	[3.2%, 3.2%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.2%	[3.2%, 3.2%]	1

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.6%	[-1.6%, -1.6%]	1
All ❌✅ (primary)	-	-	0

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.1%	[-0.1%, -0.0%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.1%	[-0.1%, -0.0%]	3

Bootstrap: 633.02s -> 632.908s (-0.02%)
Artifact size: 317.91 MiB -> 317.94 MiB (0.01%)

[RalfJung]

Would be good to have a doc comment explaining what "rigid" means.

For instance, (_, _) would be considered rigid by this check, right?

[compiler-errors]

Yeah, I can add this.