Skip to content

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

Closed
@compiler-errors

Description

@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: rust-lang/rust@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:

  • 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    T-typesAdd this label so rfcbot knows to poll the types teamfinal-comment-periodThe FCP has started, most (if not all) team members are in agreementmajor-changeA major change proposalto-announceAnnounce this issue on triage meeting

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions