Skip to content

Internal Tracking Issue for the AliasTerm refactor #156181

Open

Description

@lcnr

This is a tracking issue for a refactoring of the way aliases are represented in the type system.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

  • move DefId of type aliases into AliasTyKind ty::Alias refactor #154758
  • do the same for constants, updating AliasTerm AliasTerm refactor #155392
  • Use special DefIds for aliases #155981
  • merge AliasTy and AliasTerm and have a single Alias type generic over the kind.
  • remove AliasTerm::def_id() and AliasTy::def_id as not all variants will ahve DefIds in the future, instead track the current variant more explicitly
    • TypeError use more specific DefIds, requires change to Relate impl of AliasTy
  • replace uses of tcx.mk_ty_from_kind with calls to a more specific constructor method

Activity

  1. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    T-typesRelevant to the types team, which will review and decide on the PR/issue.
    on May 5, 2026
  2. lcnr commented on May 5, 2026

    @lcnr
    ContributorAuthor

    we should change these types as follows

    pub struct Alias<I: Interner, K> {
        pub kind: K,
        pub args: I::GenericArgs,
        pub(crate) _use_alias_new_instead: (),
    }
    
    // same for const
    type AliasTy<I: Interner> = Alias<I, AliasTyKind<I>>;

    with this we can now update NormalizesTo to also be generic over the kind, and e.g. for normalize_anon_const have the argument be Goal<I, ty::NormalizesTo<I, I::UnevaluatedConstId>>, cc #155981

  3. lcnr commented on May 5, 2026

    @lcnr
    ContributorAuthor
  4. fmease commented on May 5, 2026

    @fmease
    Member

    CC related tracking issue #154941

  5. lcnr commented on May 5, 2026

    @lcnr
    ContributorAuthor

    woops 😅

  6. khyperia commented on Jun 10, 2026

    @khyperia
    Member

    re: the step "merge AliasTy and AliasTerm and have a single Alias type generic over the kind", UnevaluatedConst should also be included in this bucket. Relatedly/tangentially, there is currently a const generics work item to rename UnevaluatedConst to AliasConst: rust-lang/project-const-generics#115

    (const items are surprisingly similar to type aliases, and generally can be thought of as the same kind of thing!)

  7. added a commit that references this issue on Jun 12, 2026
  8. added 3 commits that reference this issue on Jun 13, 2026
  9. added a commit that references this issue on Jun 13, 2026
  10. added 3 commits that reference this issue on Jun 16, 2026
  11. 10 remaining items

  12. added a commit that references this issue on Sep 18, 2026
  13. added a commit that references this issue on Sep 19, 2026
  14. added 2 commits that reference this issue on Sep 19, 2026
  15. added a commit that references this issue on Sep 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-typesRelevant to the types team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions