resolve: Support imports of associated types and glob imports from traits

[petrochenkov]

Follow up to #134754, part of #134691.
This PR also fixes an ICE in #138711.

Prohibiting use Trait::AssocType; at name resolution stage doesn't make sense, the name itself is perfectly resolveable.
It's a type checker's problem that the necessary generic args are not passed when the imported AssocType is used, so an error should be reported there.

And since we can import associated trait items now, glob imports from traits can also be allowed.

[rustbot]

r? @wesleywiser

rustbot has assigned @wesleywiser.
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

[rustbot]

HIR ty lowering was modified

cc @fmease

[petrochenkov]

#138711 is an issue for reporting some proper error here instead of this stub.

[fbstj]

Suggested change

	.struct_span_err(span, "cannot infer type, type annotations needed")
	.struct_span_err(span, "cannot infer value from uninitialized type")

from what I can tell of tests/ui/use/import_trait_associated_item_bad.rs the error isn't really type related?

[petrochenkov]

The error is copypasted from the non-min_generic_const_args case, see #138711.
(It's the Self type that cannot be inferred here.)

[bors]

☔ The latest upstream changes (presumably #138923) made this pull request unmergeable. Please resolve the merge conflicts.

[fmease]

I'm fine with lifting the restrictions from the resolver and with making HIR ty lowering responsible for dealing with it, although this PR would allow more code to compile under the unstable feature (trait T { type A; } use T::A; would start compiling (notice the lack of any use sites of A!)) plus glob imports, of course.

This deviates from the RFC. IIRC it's fine for me as a T-compiler member to approve such a change regardless and without T-lang input as long as we clearly state all of this in the tracking issue #134691, so any hypothetical future stabilization report and T-lang stabilization FCP can pick up on it.

[fmease]

I'm currently strongly leaning towards blocking this PR "on fixing #138711". I.e., implementing this in a slightly more principled manner rather than emitting artificial type inference error diagnostics depending on path segment counts which is quite fragile.

For example while e.g., [T; ASSOC_CONST] and AssocTy lead to your custom errors getting emitted, a simple change like [T; self::ASSOC_CONST] and self::AssocTy respectively — trivially bringing the segment count up to 2 — demonstrates that HIR ty lowering is already perfectly able to deal with such inputs if nudged a bit, emitting errors ambiguous associated constant and ambiguous associated type respectively (which originate from probe_single_bound_for_assoc_item).

Could you experiment with adjusting the necessary lowering methods to enable the existing machinery to handle these sorts of paths? To be totally transparent with you, I haven't thought that much about how much code that would affect.

[fmease]

I'm currently strongly leaning towards blocking this PR

The fact that the feature import_trait_associated_functions is quite recent (in design and implementation) and — for the AssocConst case — feature min_generic_const_args is still highly experimental and not yet backed by an RFC should be enough to justify my tentative decision.

[petrochenkov]

Ok, I'll look in a few days.

[fmease]

This might seem minor but the phrasing "cannot infer type" isn't quite 'right' in this context since HIR ty lowering doesn't actually use type inference (in the rustc_infer sense) or trait solving in ItemCtxts (roughly "contexts where _ is not permitted") when resolving&lowering associated types to projections, hence the phrasing "ambiguous associated type" as used by probe_single_bound…