astconv-no-mo: AstConv ⟼ HirTyLowerer

The old naming scheme is nondescript, the new one is slightly more descriptive: {compute,add}_bounds vs. lower_{mono,poly}_bounds.

This method lowers polymorphic bounds in the sense that they are potentially collectively quantified universally by an overarching / outer binder. If not, individual bounds may still be universally quantified by inner binders.

The terminology poly is preexisting, consider PolyTraitRef for example.

If I can trust my non-native English skills, the old name is beyond ungrammatical even if we include rustc jargon since adverbs cannot modify nouns.

More noteworthily, I strongly lean towards dropping the word implicit here since it violates the layers of abstraction. Indeed, some entities have implicit Sized bounds. However, we are at the lowering / elaboration layer, there's no need to state this information.

Rephrased, the hypothetical alternative name add_implicit_sized_bound wouldn't make sense semantically since one cannot add something that is implicit, add and implicit are contradictory. And if we were to make a case for implicitly add, that wouldn't make much sense either: The very action of adding is explicit — at least at this semantic layer.

The new name describes what the method does conceptually (specification-wise), while the old one describes what it does internally (implementation-wise).

Regarding item over type: This method not only lowers assoc type bindings but also assoc const bindings as well as RTN (assoc functions). Note that TypeBinding should probably renamed, too, at some point (to AssocItemBinding).

The old naming scheme is nondescript, the new one is slightly more descriptive: {compute,add}_bounds vs. lower_{mono,poly}_bounds.

This method lowers monomorphic bounds in the sense that they aren't collectively quantified universally by an overarching / outer binder. However, individual bounds may still be universally quantified by inner binders.

Therefore the term mono could be regarded as confusing by some. Note however that this is consistent with the preexisting ast_path_to_mono_trait_ref (renamed to lower_mono_trait_ref).

The old name is super nondescript. I had no idea what its job was until I read the comments and the implementation and looked at the usage sites. While the contained lengthy comment is somewhat true, namely that there is some work involved in recovering DefIds from HIR path segments and that this method implements this step, the name and the comment are misleading:

More significantly, this methods searches for path segments that are semantically allowed to have generic arguments. For example, it extracts the necessary information to reject Option::<()>::None::<()> and to accept Option::None::<()>.

Only cares about assoc types, not arbitrary assoc items.

Name disambiguated to differentiate it from probe_single_bound_for_assoc_item. Only has a single usage site, therefore length doesn't matter. It's more descriptive, too.

Before the “substs → generic args” renaming, this used to be called create_substs_for_generic_args which was more accurate.

The current name create_args_for_parent_generic_args is absolutely incorrect and confusing! We're not “creating generic args for parent generics args” but we're lowering generic args for the item whose DefId was provided (with the help of a GenericArgsLowerer) which also requires the pre-lowered parent generic args to be passed (that however is a secondary matter).

Respectfully, I think the author of the renaming PR saw the parent_args parameter and thought that the parent args were being lowered.

Before the “substs → generic args” renaming, this used to be called CreateSubstsForGenericArgsCtxt which was more accurate. Respectfully, the author of the renaming PR shouldn't have chosen the word “instantiations” here (I noted that on the PR after it was merged).

This trait models contexts that can lower hir::GenericArgs to ty::GenericArgs. The new name is succinct and mirrors the naming of trait HirTyLowerer.