remove AliasTy::def_id()#158013
Conversation
rustbot
added
S-waiting-on-review
rustbot
added
the
WG-trait-system-refactor
|
|
| self.opt_rpitit_info(def_id).is_some() | ||
| } | ||
|
|
||
| pub fn get_impl_future_output_ty(self, ty: Ty<'tcx>) -> Option<Ty<'tcx>> { |
There was a problem hiding this comment.
I moved this from TypeErrCtxt to TyCtxt... maybe I should split this to another commit
| 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>>; |
There was a problem hiding this comment.
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)
|
|
||
| let (ty::Projection { def_id } | ty::Inherent { def_id }) = proj_ty.kind else { | ||
| panic!("expected projection or inherent alias, found {:?}", proj_ty.kind); | ||
| }; |
There was a problem hiding this comment.
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
| 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, *}; |
There was a problem hiding this comment.
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)
| ty::Opaque { def_id: key.def_id.into() }, | ||
| key.args, | ||
| ) | ||
| .try_to_opaque() |
There was a problem hiding this comment.
hmm, why this indirection?
There was a problem hiding this comment.
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-baseddebug_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
4 participants
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 codefyi @lcnr
r? @BoxyUwU