-
-
Notifications
You must be signed in to change notification settings - Fork 15k
remove AliasTy::def_id() #158013
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
remove AliasTy::def_id() #158013
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2704,6 +2704,39 @@ impl<'tcx> TyCtxt<'tcx> { | |
| self.opt_rpitit_info(def_id).is_some() | ||
| } | ||
|
|
||
| pub fn get_impl_future_output_ty(self, ty: Ty<'tcx>) -> Option<Ty<'tcx>> { | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I moved this from TypeErrCtxt to TyCtxt... maybe I should split this to another commit
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. could be nice yeah, but also was fine as is for me when reviewing |
||
| let (def_id, args) = match *ty.kind() { | ||
| ty::Alias(ty::AliasTy { kind: ty::Opaque { def_id }, args, .. }) => (def_id, args), | ||
| ty::Alias(ty::AliasTy { kind: ty::Projection { def_id }, args, .. }) | ||
| if self.is_impl_trait_in_trait(def_id) => | ||
| { | ||
| (def_id, args) | ||
| } | ||
| _ => return None, | ||
| }; | ||
|
|
||
| let future_trait = self.require_lang_item(LangItem::Future, DUMMY_SP); | ||
| let item_def_id = self.associated_item_def_ids(future_trait)[0]; | ||
|
|
||
| self.explicit_item_self_bounds(def_id) | ||
| .iter_instantiated_copied(self, args) | ||
| .map(ty::Unnormalized::skip_norm_wip) | ||
| .find_map(|(predicate, _)| { | ||
| predicate | ||
| .kind() | ||
| .map_bound(|kind| match kind { | ||
| ty::ClauseKind::Projection(projection_predicate) | ||
| if projection_predicate.def_id() == item_def_id => | ||
| { | ||
| projection_predicate.term.as_type() | ||
| } | ||
| _ => None, | ||
| }) | ||
| .no_bound_vars() | ||
| .flatten() | ||
| }) | ||
| } | ||
|
|
||
| /// Named module children from all kinds of items, including imports. | ||
| /// In addition to regular items this list also includes struct and variant constructors, and | ||
| /// items inside `extern {}` blocks because all of them introduce names into parent module. | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -38,6 +38,11 @@ pub type TyKind<'tcx> = ir::TyKind<TyCtxt<'tcx>>; | |
| pub type TypeAndMut<'tcx> = ir::TypeAndMut<TyCtxt<'tcx>>; | ||
| pub type AliasTy<'tcx> = ir::AliasTy<TyCtxt<'tcx>>; | ||
| pub type AliasTyKind<'tcx> = ir::AliasTyKind<TyCtxt<'tcx>>; | ||
| pub type Alias<'tcx, K> = ir::Alias<TyCtxt<'tcx>, K>; | ||
| 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>>; | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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 |
||
| pub type FnSig<'tcx> = ir::FnSig<TyCtxt<'tcx>>; | ||
| pub type FnSigKind<'tcx> = ir::FnSigKind<TyCtxt<'tcx>>; | ||
| pub type Binder<'tcx, T> = ir::Binder<TyCtxt<'tcx>, T>; | ||
|
|
@@ -477,12 +482,22 @@ impl<'tcx> Ty<'tcx> { | |
|
|
||
| #[inline] | ||
| pub fn new_alias(tcx: TyCtxt<'tcx>, alias_ty: ty::AliasTy<'tcx>) -> Ty<'tcx> { | ||
| debug_assert_matches!( | ||
| (alias_ty.kind, tcx.def_kind(alias_ty.kind.def_id())), | ||
| (ty::Opaque { .. }, DefKind::OpaqueTy) | ||
| | (ty::Projection { .. } | ty::Inherent { .. }, DefKind::AssocTy) | ||
| | (ty::Free { .. }, DefKind::TyAlias) | ||
| ); | ||
| if cfg!(debug_assertions) { | ||
| match alias_ty.kind { | ||
| ty::AliasTyKind::Projection { def_id } => { | ||
| debug_assert_matches!(tcx.def_kind(def_id), DefKind::AssocTy) | ||
| } | ||
| ty::AliasTyKind::Inherent { def_id } => { | ||
| debug_assert_matches!(tcx.def_kind(def_id), DefKind::AssocTy) | ||
| } | ||
| ty::AliasTyKind::Opaque { def_id } => { | ||
| debug_assert_matches!(tcx.def_kind(def_id), DefKind::OpaqueTy) | ||
| } | ||
| ty::AliasTyKind::Free { def_id } => { | ||
| debug_assert_matches!(tcx.def_kind(def_id), DefKind::TyAlias) | ||
| } | ||
| } | ||
| } | ||
| Ty::new(tcx, Alias(alias_ty)) | ||
| } | ||
|
|
||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, why this indirection?
View changes since the review
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is currently no way to construct a OpaqueAliasTy directly (in particular, I want to make sure
debug_assert_args_compatibleis called).T: Into<AliasTerm>, and then call an AliasTerm-baseddebug_assert_args_compatible?.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::OpaqueTyIdnot being a newtype wrapper -I::OpaqueTyIdcan't implInto<AliasTerm>at the moment, it's just aDefId). Happy to refactor, I just dunno what the nicest thing to do isThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 😌