Rust: Path resolution for inherited associated items

[hvitved]

Functions inherited through trait bounds or impl blocks are now modeled in the path resolution logic.

[paldepind]

Suggested change

	or
	// an inherited function, either from a trait bound or from an `impl` block
	exists(ItemNode node |
	result = node.(ItemNode).getASuccessorRec(name) and
	result instanceof Function
	|
	node = this.(TraitItemNode).resolveABound()
	or
	this = node.(ImplItemNode).resolveSelfTy()
	)
	// a trait has access to the associated items of its supertraits
	result = this.(TraitItemNode).resolveABound().getASuccessorRec(name)
	or
	// items made available by an implementation where `this` is the implementing type
	exists(ItemNode node |
	this = node.(ImplItemNode).resolveSelfTy() and
	result = node.getASuccessorRec(name)
	)

Thoughts:

• Splits this into two cases which I think is easier to read.
• Doesn't use the word "inherited". The word makes sense, but also has some OO baggage and Rust is usually said to not have inheritance.
• Removes the instanceof Function. From reading the docs I don't think that restriction is correct. This text seems to indicate that subtraits get access to everything (not just functions). The example here shows how a path (color::Color::WHITE) can refer to a const in an impl block. If that is correct, it would probably be a good idea to include tests for those things as well.
• Is the use of resolveABound precise? A trait can have bounds that are not on Self and those don't lead to a supertrait.

[hvitved]

All good points.

Splits this into two cases which I think is easier to read.

Will do.

Removes the instanceof Function. From reading the docs I don't think that restriction is correct. This text seems to indicate that subtraits get access to everything (not just functions). The example here shows how a path (color::Color::WHITE) can refer to a const in an impl block. If that is correct, it would probably be a good idea to include tests for those things as well.

I'll instead formulate the restriction positively using AssocItem; for example, sub traits should not have access to type parameters of super traits.

Is the use of resolveABound precise? A trait can have bounds that are not on Self and those don't lead to a supertrait.

resolveABound only looks at TypeBoundList, and not WhereClause (which should be done follow-up).

[paldepind]

I'll instead formulate the restriction positively using AssocItem; for example, sub traits should not have access to type parameters of super traits.

I see. AssocItem is exactly what we need then 👍

resolveABound only looks at TypeBoundList, and not WhereClause (which should be done follow-up).

Great, thanks :)

[paldepind]

LGTM! 🎉