Combine `ty::Opaque` and `ty::Projection` into `ty::Alias`

[compiler-errors]

Combine ty::Opaque and ty::Projection into ty::Alias

Aims to combine ty::Opaque and ty::Projection into ty::Alias. Both are just a def-id and set of substitutions. We should also be able to easily add new alias variants in the future if needed.

The new TyKind API will somewhat look like:

enum TyKind {
  ..
  // New variant, remove `TyKind::{Opaque, Projection}`
  Alias(AliasKind, AliasTy),
  ..
}

enum AliasKind {
  Opaque,
  Projection,
}

// Replaces `ProjectionTy`
struct AliasTy<'tcx> {
  def_id: DefId,
  substs: SubstsRef<'tcx>,
}

To make sure that code can still match on the old usages ty::Opaque and ty::Projection, we distinguish the variants with AliasKind. This is important in places where we don't have access to TyCtxt, such as flags computation. Also, it would be somewhat expensive to add new def-id comparisons.

This means most match sites can go from ty::Projection(proj) to ty::Alias(ty::Projection, proj), meaning the refactor will be mostly mechanical.

The API is somewhat different from the way that Chalk does it, where AliasTy is an enum with a data-ful Projection and Opaque variant: https://docs.rs/chalk-ir/0.87.0/chalk_ir/enum.AliasTy.html

Mentors or Reviewers

@compiler-errors's implementation: https://github.com/rust-lang/rust/compare/master...compiler-errors:rust:opaques _{still needs some cleaning, but only took like an hour or so.. also we might want to tweak the API a bit...}

The change is mostly mechanical, so anyone on the team can review.

Process

The main points of the Major Change Process are as follows:

• [x] File an issue describing the proposal.
• [ ] A types team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Types team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• [ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/types

[oli-obk]

@rustbot second

[lcnr]

we still have to manually close those :grin: