remove AliasTy::def_id() by khyperia · Pull Request #158013 · rust-lang/rust

khyperia · 2026-06-17T09:09:35Z

this is part of #156181

as well as part of #152245

this immediately uses the recently-introduced Alias<> type to narrow the kinds of aliases allowed in various places in code

fyi @lcnr

r? @BoxyUwU

rustbot · 2026-06-17T09:09:39Z

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a, @makai410

clippy is developed in its own repository. If possible, consider making this change to rust-lang/rust-clippy instead.

cc @rust-lang/clippy

HIR ty lowering was modified

cc @fmease

rustbot · 2026-06-17T09:09:42Z

BoxyUwU is currently at their maximum review capacity.
They may take a while to respond.

khyperia · 2026-06-17T09:11:11Z

        self.opt_rpitit_info(def_id).is_some()
    }

+    pub fn get_impl_future_output_ty(self, ty: Ty<'tcx>) -> Option<Ty<'tcx>> {


I moved this from TypeErrCtxt to TyCtxt... maybe I should split this to another commit

View changes since the review

could be nice yeah, but also was fine as is for me when reviewing

khyperia · 2026-06-17T09:12:50Z

+pub type ProjectionAliasTy<'tcx> = ir::ProjectionAliasTy<TyCtxt<'tcx>>;
+pub type InherentAliasTy<'tcx> = ir::InherentAliasTy<TyCtxt<'tcx>>;
+pub type OpaqueAliasTy<'tcx> = ir::OpaqueAliasTy<TyCtxt<'tcx>>;
+pub type FreeAliasTy<'tcx> = ir::FreeAliasTy<TyCtxt<'tcx>>;


some of these are unused... I'm not sure what the preference is here, if we should have unused useful things that fill out a "pattern", or if we should strictly add only what is actually used. (same question for try_to_inherent and stuff)

View changes since the review

khyperia · 2026-06-17T09:15:51Z


+        let (ty::Projection { def_id } | ty::Inherent { def_id }) = proj_ty.kind else {
+            panic!("expected projection or inherent alias, found {:?}", proj_ty.kind);
+        };


these variants were guarded against and and def_id fetched in the caller... there's sort of three ways to handle this:

guard in the caller, pass in the matched def_id as an additional argument alongside proj_ty

guard again in the callee, here, panicing if it's wrong (what I kind of arbitrarily chose to do here, and what I did in previous PRs)

create another Kind enum, for just Projection/Inherent, and pass in an Alias<> with that kind

View changes since the review

panic'ing seems fine for now 🤔 needing a ProjectionOrInherentAlias seems like maybe slightly overkill

khyperia · 2026-06-17T09:18:18Z

 pub use rustc_ast_ir::{FloatTy, IntTy, Movability, Mutability, Pinnedness, UintTy};
 use rustc_type_ir_macros::GenericTypeVisitable;
-pub use ty::{Alias, AliasTerm, AliasTy, UnevaluatedConst};
+pub use ty::{Alias, *};


unrelated to this PR, I realized there's a conflict here - rustc_type_ir::Alias used to resolve to the TyKind::Alias variant, now it's the Alias struct. A bit unfortunate, but fine I guess.

(also IMO having a nested ty module (recently added, in the Alias<> PR) is very confusing (since rustc_type_ir is itself imported with the alias name of ty absolutely everywhere in the compiler), but oh well)

View changes since the review

lcnr · 2026-06-17T13:10:30Z

+                                ty::Opaque { def_id: key.def_id.into() },
+                                key.args,
+                            )
+                            .try_to_opaque()


hmm, why this indirection?

View changes since the review

there is currently no way to construct a OpaqueAliasTy directly (in particular, I want to make sure debug_assert_args_compatible is called).

option 1: make a bespoke constructor for OpaqueAliasTy (and optionally Projection/Inherent/Free too, depending on the policy on unused code, I'm not sure)

option 2: some kind of generic constructor, hmm. Maybe one that takes T: Into<AliasTerm>, and then call an AliasTerm-based debug_assert_args_compatible?

option 3: hit it with a stupid hammer and use the AliasTy constructor and .try_to_opaque()

I went with option 3 :s (option 1 I was nervous about unused code, option 2 runs into the issue that we talked about of I::OpaqueTyId not being a newtype wrapper - I::OpaqueTyId can't impl Into<AliasTerm> at the moment, it's just a DefId). Happy to refactor, I just dunno what the nicest thing to do is

I think that 1 is fine, id personally kinda bias towards adding all the dead code for the other kinds of aliases just so it's less annoying when they do actually need to be used, but it's also fine to only add the stuff actually needed 😌

BoxyUwU · 2026-06-19T12:44:52Z

looked over it seems good to me :3

BoxyUwU · 2026-06-19T12:45:52Z

@rustbot author

rustbot · 2026-06-19T12:45:57Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

khyperia · 2026-06-20T09:21:07Z

@rustbot ready

Shourya742

LGTM. I have a few questions, but overall the changes were easy to follow and understand. Thanks.

View changes since this review

Shourya742 · 2026-06-21T11:15:36Z

                                        .tcx
                                        .infer_ctxt()
                                        .build(cx.typing_mode())
-                                        .err_ctxt()
+                                        .tcx


I think we may no longer need to construct an InferCtxt here. If I understand correctly, it was previously required to obtain an err_ctxt and then call get_impl_future_output_ty. Since we already have access to tcx, would it make sense to call cx.tcx.get_impl_future_output_ty(ret_ty) directly instead (as we moved it to tcx)?

good point! I did the move too quickly and didn't realize we could skip building it entirely. Nice, pushed!

Shourya742 · 2026-06-21T11:20:11Z

@@ -36,7 +35,7 @@ fn result_err_ty<'tcx>(
                .tcx
                .infer_ctxt()
                .build(cx.typing_mode())
-                .err_ctxt()
+                .tcx


I think this follows the same, we can directly use tcx?

Shourya742 · 2026-06-21T11:22:13Z

            let infcx = cx.tcx.infer_ctxt().build(cx.typing_mode());
-            if let Some(future_ty) = infcx.err_ctxt().get_impl_future_output_ty(return_ty(cx, item_id))
+            if let Some(future_ty) = infcx.tcx.get_impl_future_output_ty(return_ty(cx, item_id))


I think follows the same, we can use cx.tcx.get_impl_future_output_ty?

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-clippy Relevant to the Clippy team. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 17, 2026

rustbot assigned BoxyUwU Jun 17, 2026

rustbot added the WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) label Jun 17, 2026

khyperia commented Jun 17, 2026

View reviewed changes

lcnr reviewed Jun 17, 2026

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 19, 2026

khyperia force-pushed the AliasTy-def_id branch from cbebdcc to 6f01be5 Compare June 20, 2026 09:19

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 20, 2026

Shourya742 reviewed Jun 21, 2026

View reviewed changes

remove AliasTy::def_id()

992c2de

khyperia force-pushed the AliasTy-def_id branch from 6f01be5 to 992c2de Compare June 21, 2026 11:33

Uh oh!

Conversation

khyperia commented Jun 17, 2026

Uh oh!

rustbot commented Jun 17, 2026

Uh oh!

rustbot commented Jun 17, 2026

Uh oh!

khyperia Jun 17, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

khyperia Jun 17, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

khyperia Jun 17, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

khyperia Jun 17, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lcnr Jun 17, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BoxyUwU commented Jun 19, 2026

Uh oh!

BoxyUwU commented Jun 19, 2026

Uh oh!

rustbot commented Jun 19, 2026

Uh oh!

khyperia commented Jun 20, 2026

Uh oh!

Shourya742 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

khyperia Jun 17, 2026 •

edited by rustbot

Loading

khyperia Jun 17, 2026 •

edited by rustbot

Loading

khyperia Jun 17, 2026 •

edited by rustbot

Loading

khyperia Jun 17, 2026 •

edited by rustbot

Loading

lcnr Jun 17, 2026 •

edited by rustbot

Loading

Shourya742 left a comment •

edited by rustbot

Loading