Prefer using rustc_middle::ty types over rustc_hir ones

[Nadrieril]

A number of rustc types have two versions: one in the HIR, the other in rustc_middle::ty. For example GenericParam vs GenericParamDef or WherePredicate vs Predicate. The HIR version is more syntactic, the ty version is more semantic.

We often copy both versions in the frontend, because they happen to show up in other types we need. I propose that when possible we substitute the ty version for the HIR one, as I suspect the ty ones are more convenient to use for our purposes.

[github-actions]

This issue has been marked as stale due to a lack of activity for 60 days. If you believe this issue is still relevant, please provide an update or comment to keep it open. Otherwise, it will be closed in 7 days.

[W95Psp]

Still relevant

[Nadrieril]

List of types we can migrate this way:

• hir::GenericParam -> ty::GenericParam
• hir::Generics -> ty::GenericArg
• hir::Ty -> we should never interact with this, only ty::Ty
• hir::FieldDef -> ty::FieldDef
• hir::FnSig -> ty::PolyFnSig

After that, the most powerful change we could do would be to migrate from hir::Item to hax::FullDef. This would transitively allow removing ~30 hir::* types without needing to add any new ones.

List of `hir::*` types that are only used transitively by one of the above types:

• hir::AnonConst
• hir::AssocItemKind
• hir::ConstArg
• hir::ConstArgKind
• hir::Constness
• hir::EnumDef
• hir::FnDecl
• hir::FnHeader
• hir::FnRetTy
• hir::ForeignItem
• hir::ForeignItemKind
• hir::ForeignItemRef
• hir::GenericBounds
• hir::GenericParamKind
• hir::Impl
• hir::ImplItem
• hir::ImplItemKind
• hir::ImplItemRef
• hir::ImplPolarity
• hir::IsAsync
• hir::IsAuto
• hir::ItemId
• hir::ItemKind
• hir::LifetimeParamKind
• hir::Mod
• hir::OpaqueTy
• hir::OpaqueTyOrigin
• hir::ParamName
• hir::PathSegment
• hir::PrimTy
• hir::TraitItem
• hir::TraitItemKind
• hir::TraitItemRef
• hir::UseKind
• hir::UsePath
• hir::Variant
• hir::VariantData