Check compare_impl_item before resolving free-item consts

[biscuitrescue]

Fixes #161532.

Problem

An associated const whose generic parameter type mismatches between trait declaration and its impl is correctly rejected with code E0053 with the following reproducing code, but doesn't stop compilation and evaluates the impl's K anyway and hits an internal scalar_immediate size does not match layout assertion, since the impl body expected a u32, but the args were evaluated against the trait's expected u16

#![feature(generic_const_args)]
#![feature(min_generic_const_args)]
#![feature(generic_const_items)]

trait Owner {
    const K<const N: u16>: u32;
}

impl Owner for () {
    const K<const N: u32>: u32 = N + 1;

fn main() {}

Root cause

resolve_instance_raw can go on two paths:

• When def_id is a trait item, resolve_associated_item runs and already guards against this exact case by calling
  compare_impl_item before resolving to the impl's definition.

• When def_id is already a concrete item, as happens here when the next-generation trait solver's evaluate_const_and_instantiate_projection_term resolves the projection directly to the impl's K, trait_of_assoc returns None which leads to the free-item branch running instead, which has never checked compare_impl_item at all.

Fix

Added the same compare_impl_item guard to the free-item branch, gated on the item actually overriding a trait item
(trait_item_def_id().is_some()). This rejects an E0053-tainted impl item before evaluation.

Testing

Added tests/ui/const-generics/mismatched-assoc-const-generic-ice.rs reproducing the original ICE. With the fix, only the E0053 is reported and compilation aborts cleanly.

Note: an earlier attempt guarded confirm_impl_candidate (the old-solver projection-confirmation path) instead that never fired for this since resolution goes through the next-gen solver, and produces a different ICE. Mentioning it here in case it's useful context for reviewers, though it's not a part of this diff.

[rustbot]

r? @Enselic

rustbot has assigned @Enselic.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 76 candidates
• Random selection from 22 candidates

[fmease]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 6a59b21 (6a59b21bef4346f37e624f093bf38fa2ad425190)
Base parent: ca0a647 (ca0a6473ffde01deb7fce24cc04864cf723e14a0)

[rust-timer]

Finished benchmarking commit (6a59b21): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

Results (primary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.6%, 0.6%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.8%	[-1.0%, -0.6%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.1%	[-1.0%, 0.6%]	4

Cycles

Results (primary -0.2%, secondary -4.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.5%, 0.9%]	3
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-1.1%, -0.4%]	5
Improvements ✅ (secondary)	-4.3%	[-7.5%, -2.5%]	10
All ❌✅ (primary)	-0.2%	[-1.1%, 0.9%]	8

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 494.036s -> 493.96s (-0.02%)
Artifact size: 407.63 MiB -> 406.94 MiB (-0.17%)