Delegation: fix ICE on duplicated associative items

[Bryanskiy]

Currently, functions delegation is only supported for delegation items with early resolved paths e.g. free functions and trait methods. During name resolution, information about function signatures is collected, including the number of parameters and whether there are self arguments. This information is then used when lowering from a delegation item into a regular function(rustc_ast_lowering/src/delegation.rs). The signature is usually inherited from path resolution id(path_id). However, in the case of trait impls path_id and item_id may be different:

trait Trait {
    fn foo(&self) -> u32 { 0 }
}

struct S;

mod to_reuse {
    use crate::S;

    pub fn foo(_: &S) -> u32 { 0 }
}

impl Trait for S {
    reuse to_reuse::foo { self }
    //~^ The signature should be inherited from item id instead of resolution id
}

Let's now consider an example from issue. Due to duplicated associative elements partial resolution for one of them will not be recorded:

rust/compiler/rustc_resolve/src/late.rs

Lines 3153 to 3162 in 9023f90

	Entry::Occupied(entry) => {
	self.report_error(
	span,
	ResolutionError::TraitImplDuplicate {
	name: ident.name,
	old_span: *entry.get(),
	trait_item_span: binding.span,
	},
	);
	return;

Which leads to an incorrect is_in_trait_impl

rust/compiler/rustc_ast_lowering/src/item.rs

Lines 981 to 986 in 9023f90

	let trait_item_def_id = self
	.resolver
	.get_partial_res(i.id)
	.map(|r| r.expect_full_res().opt_def_id())
	.unwrap_or(None);
	self.is_in_trait_impl = trait_item_def_id.is_some();

Which leads to an incorrect id for signature inheritance

rust/compiler/rustc_ast_lowering/src/delegation.rs

Lines 99 to 105 in 9023f90

	fn get_delegation_sig_id(
	&self,
	item_id: NodeId,
	path_id: NodeId,
	span: Span,
	) -> Result<DefId, ErrorGuaranteed> {
	let sig_id = if self.is_in_trait_impl { item_id } else { path_id };

Which lead to an ICE from original issue.

This patch fixes wrong is_in_trait_impl calculation.

fixes #119920

[compiler-errors]

Could you please explain in the PR description why this fixes what it does? All that I can tell is that this PR changes some state tracking in the LoweringContext, which is confusing enough as it is.

[compiler-errors]

@rustbot author

[petrochenkov]

r? @compiler-errors

[Bryanskiy]

@rustbot ready

[compiler-errors]

@bors r+

[bors]

📌 Commit b2ed9d0 has been approved by compiler-errors

It is now in the queue for this repository.