1
Fork 0
rust/compiler/rustc_middle/src/ty/structural_impls.rs

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

715 lines
23 KiB
Rust
Raw Normal View History

//! This module contains implementations of the `Lift`, `TypeFoldable` and
//! `TypeVisitable` traits for various types in the Rust compiler. Most are
//! written by hand, though we've recently added some macros and proc-macros
//! to help with the tedium.
use crate::mir::interpret;
2022-08-23 01:13:07 -04:00
use crate::mir::{Field, ProjectionKind};
2023-02-22 02:18:40 +00:00
use crate::ty::fold::{FallibleTypeFolder, TypeFoldable, TypeSuperFoldable};
use crate::ty::print::{with_no_trimmed_paths, FmtPrinter, Printer};
2023-02-22 02:18:40 +00:00
use crate::ty::visit::{TypeSuperVisitable, TypeVisitable, TypeVisitor};
use crate::ty::{self, AliasTy, InferConst, Lift, Term, TermKind, Ty, TyCtxt};
use rustc_hir::def::Namespace;
use rustc_index::vec::{Idx, IndexVec};
use rustc_target::abi::TyAndLayout;
2015-09-06 21:51:58 +03:00
use std::fmt;
use std::ops::ControlFlow;
2015-09-06 21:51:58 +03:00
use std::rc::Rc;
2019-06-18 08:15:27 -04:00
use std::sync::Arc;
2015-09-06 21:51:58 +03:00
impl fmt::Debug for ty::TraitDef {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
ty::tls::with(|tcx| {
with_no_trimmed_paths!({
f.write_str(
&FmtPrinter::new(tcx, Namespace::TypeNS)
.print_def_path(self.def_id, &[])?
.into_buffer(),
)
})
})
}
}
impl<'tcx> fmt::Debug for ty::AdtDef<'tcx> {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
ty::tls::with(|tcx| {
with_no_trimmed_paths!({
f.write_str(
&FmtPrinter::new(tcx, Namespace::TypeNS)
.print_def_path(self.did(), &[])?
.into_buffer(),
)
})
})
}
}
impl fmt::Debug for ty::UpvarId {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
let name = ty::tls::with(|tcx| tcx.hir().name(self.var_path.hir_id));
write!(f, "UpvarId({:?};`{}`;{:?})", self.var_path.hir_id, name, self.closure_expr_id)
}
}
impl<'tcx> fmt::Debug for ty::ExistentialTraitRef<'tcx> {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
with_no_trimmed_paths!(fmt::Display::fmt(self, f))
}
}
impl<'tcx> fmt::Debug for ty::adjustment::Adjustment<'tcx> {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
write!(f, "{:?} -> {}", self.kind, self.target)
}
}
impl fmt::Debug for ty::BoundRegionKind {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
match *self {
ty::BrAnon(n, span) => write!(f, "BrAnon({n:?}, {span:?})"),
ty::BrNamed(did, name) => {
if did.is_crate_root() {
write!(f, "BrNamed({})", name)
} else {
write!(f, "BrNamed({:?}, {})", did, name)
}
}
ty::BrEnv => write!(f, "BrEnv"),
}
}
}
impl fmt::Debug for ty::FreeRegion {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
write!(f, "ReFree({:?}, {:?})", self.scope, self.bound_region)
}
}
impl<'tcx> fmt::Debug for ty::FnSig<'tcx> {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
write!(f, "({:?}; c_variadic: {})->{:?}", self.inputs(), self.c_variadic, self.output())
}
}
impl<'tcx> fmt::Debug for ty::ConstVid<'tcx> {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
write!(f, "_#{}c", self.index)
}
}
impl<'tcx> fmt::Debug for ty::TraitRef<'tcx> {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
with_no_trimmed_paths!(fmt::Display::fmt(self, f))
}
}
impl<'tcx> fmt::Debug for Ty<'tcx> {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
with_no_trimmed_paths!(fmt::Display::fmt(self, f))
}
}
impl fmt::Debug for ty::ParamTy {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
write!(f, "{}/#{}", self.name, self.index)
}
}
impl fmt::Debug for ty::ParamConst {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
write!(f, "{}/#{}", self.name, self.index)
}
}
impl<'tcx> fmt::Debug for ty::TraitPredicate<'tcx> {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
2021-08-27 05:02:23 +00:00
if let ty::BoundConstness::ConstIfConst = self.constness {
write!(f, "~const ")?;
2021-07-22 21:56:07 +08:00
}
2021-10-11 18:10:35 -03:00
write!(f, "TraitPredicate({:?}, polarity:{:?})", self.trait_ref, self.polarity)
}
}
impl<'tcx> fmt::Debug for ty::ProjectionPredicate<'tcx> {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
write!(f, "ProjectionPredicate({:?}, {:?})", self.projection_ty, self.term)
}
}
impl<'tcx> fmt::Debug for ty::Predicate<'tcx> {
2020-05-11 22:06:41 +02:00
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
2021-01-07 11:20:28 -05:00
write!(f, "{:?}", self.kind())
2020-05-11 22:06:41 +02:00
}
}
2022-11-24 18:14:58 -03:00
impl<'tcx> fmt::Debug for ty::Clause<'tcx> {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
match *self {
2023-02-16 11:55:58 +00:00
ty::Clause::ConstArgHasType(ct, ty) => write!(f, "ConstArgHasType({ct:?}, {ty:?})"),
2022-11-24 18:14:58 -03:00
ty::Clause::Trait(ref a) => a.fmt(f),
ty::Clause::RegionOutlives(ref pair) => pair.fmt(f),
ty::Clause::TypeOutlives(ref pair) => pair.fmt(f),
ty::Clause::Projection(ref pair) => pair.fmt(f),
}
}
}
impl<'tcx> fmt::Debug for ty::PredicateKind<'tcx> {
2020-07-09 00:35:55 +02:00
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
match *self {
2022-11-24 18:14:58 -03:00
ty::PredicateKind::Clause(ref a) => a.fmt(f),
2021-01-07 11:20:28 -05:00
ty::PredicateKind::Subtype(ref pair) => pair.fmt(f),
2020-11-21 07:06:16 -05:00
ty::PredicateKind::Coerce(ref pair) => pair.fmt(f),
2021-01-07 11:20:28 -05:00
ty::PredicateKind::WellFormed(data) => write!(f, "WellFormed({:?})", data),
ty::PredicateKind::ObjectSafe(trait_def_id) => {
write!(f, "ObjectSafe({:?})", trait_def_id)
}
2021-01-07 11:20:28 -05:00
ty::PredicateKind::ClosureKind(closure_def_id, closure_substs, kind) => {
write!(f, "ClosureKind({:?}, {:?}, {:?})", closure_def_id, closure_substs, kind)
}
ty::PredicateKind::ConstEvaluatable(ct) => {
write!(f, "ConstEvaluatable({ct:?})")
}
2021-01-07 11:20:28 -05:00
ty::PredicateKind::ConstEquate(c1, c2) => write!(f, "ConstEquate({:?}, {:?})", c1, c2),
ty::PredicateKind::TypeWellFormedFromEnv(ty) => {
2020-09-01 17:58:34 +02:00
write!(f, "TypeWellFormedFromEnv({:?})", ty)
}
ty::PredicateKind::Ambiguous => write!(f, "Ambiguous"),
2023-02-10 13:43:29 +00:00
ty::PredicateKind::AliasEq(t1, t2) => write!(f, "AliasEq({t1:?}, {t2:?})"),
}
}
}
impl<'tcx> fmt::Debug for AliasTy<'tcx> {
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
f.debug_struct("AliasTy")
.field("substs", &self.substs)
.field("def_id", &self.def_id)
.finish()
}
}
///////////////////////////////////////////////////////////////////////////
// Atomic structs
//
// For things that don't carry any arena-allocated data (and are
// copy...), just add them to one of these lists as appropriat.
// For things for which the type library provides traversal implementations
// for all Interners, we only need to provide a Lift implementation:
CloneLiftImpls! {
(),
bool,
usize,
u16,
u32,
u64,
2018-11-26 17:30:19 +01:00
String,
rustc_type_ir::DebruijnIndex,
}
// For things about which the type library does not know, or does not
// provide any traversal implementations, we need to provide both a Lift
// implementation and traversal implementations (the latter only for
// TyCtxt<'_> interners).
TrivialTypeTraversalAndLiftImpls! {
::rustc_target::abi::VariantIdx,
2019-02-05 11:20:45 -06:00
crate::middle::region::Scope,
crate::ty::FloatTy,
2020-04-27 23:26:11 +05:30
::rustc_ast::InlineAsmOptions,
::rustc_ast::InlineAsmTemplatePiece,
::rustc_ast::NodeId,
::rustc_span::symbol::Symbol,
::rustc_hir::def::Res,
::rustc_hir::def_id::DefId,
2020-07-08 01:03:19 +02:00
::rustc_hir::def_id::LocalDefId,
::rustc_hir::HirId,
::rustc_hir::MatchSource,
::rustc_hir::Mutability,
::rustc_hir::Unsafety,
2020-02-14 18:17:50 +00:00
::rustc_target::asm::InlineAsmRegOrRegClass,
::rustc_target::spec::abi::Abi,
crate::mir::coverage::ExpressionOperandId,
crate::mir::coverage::CounterValueReference,
crate::mir::coverage::InjectedExpressionId,
crate::mir::coverage::InjectedExpressionIndex,
crate::mir::coverage::MappedExpressionIndex,
2019-02-05 11:20:45 -06:00
crate::mir::Local,
crate::mir::Promoted,
crate::traits::Reveal,
crate::ty::adjustment::AutoBorrowMutability,
crate::ty::AdtKind,
2021-08-27 05:02:23 +00:00
crate::ty::BoundConstness,
// Including `BoundRegionKind` is a *bit* dubious, but direct
// references to bound region appear in `ty::Error`, and aren't
// really meant to be folded. In general, we can only fold a fully
// general `Region`.
crate::ty::BoundRegionKind,
crate::ty::AssocItem,
crate::ty::AssocKind,
crate::ty::AliasKind,
crate::ty::Placeholder<crate::ty::BoundRegionKind>,
2023-01-17 03:27:48 +00:00
crate::ty::Placeholder<crate::ty::BoundTyKind>,
2019-02-05 11:20:45 -06:00
crate::ty::ClosureKind,
crate::ty::FreeRegion,
crate::ty::InferTy,
2019-02-05 11:20:45 -06:00
crate::ty::IntVarValue,
crate::ty::ParamConst,
2019-02-05 11:20:45 -06:00
crate::ty::ParamTy,
crate::ty::adjustment::PointerCast,
crate::ty::RegionVid,
2019-02-05 11:20:45 -06:00
crate::ty::UniverseIndex,
crate::ty::Variance,
::rustc_span::Span,
::rustc_errors::ErrorGuaranteed,
Field,
interpret::Scalar,
rustc_target::abi::Size,
ty::BoundVar,
ty::Placeholder<ty::BoundVar>,
}
TrivialTypeTraversalAndLiftImpls! {
for<'tcx> {
ty::ValTree<'tcx>,
}
}
2015-09-06 21:51:58 +03:00
///////////////////////////////////////////////////////////////////////////
// Lift implementations
impl<'tcx, A: Lift<'tcx>, B: Lift<'tcx>> Lift<'tcx> for (A, B) {
type Lifted = (A::Lifted, B::Lifted);
2020-10-16 21:59:49 +02:00
fn lift_to_tcx(self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {
2020-10-21 23:52:41 +02:00
Some((tcx.lift(self.0)?, tcx.lift(self.1)?))
2015-09-06 21:51:58 +03:00
}
}
2016-12-26 14:34:03 +01:00
impl<'tcx, A: Lift<'tcx>, B: Lift<'tcx>, C: Lift<'tcx>> Lift<'tcx> for (A, B, C) {
type Lifted = (A::Lifted, B::Lifted, C::Lifted);
2020-10-16 21:59:49 +02:00
fn lift_to_tcx(self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {
2020-10-21 23:52:41 +02:00
Some((tcx.lift(self.0)?, tcx.lift(self.1)?, tcx.lift(self.2)?))
2019-06-18 08:52:23 -04:00
}
2016-12-26 14:34:03 +01:00
}
impl<'tcx, T: Lift<'tcx>> Lift<'tcx> for Option<T> {
type Lifted = Option<T::Lifted>;
2020-10-16 21:59:49 +02:00
fn lift_to_tcx(self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {
2022-09-21 08:29:19 +00:00
Some(match self {
Some(x) => Some(tcx.lift(x)?),
None => None,
})
}
}
impl<'tcx, T: Lift<'tcx>, E: Lift<'tcx>> Lift<'tcx> for Result<T, E> {
type Lifted = Result<T::Lifted, E::Lifted>;
2020-10-16 21:59:49 +02:00
fn lift_to_tcx(self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {
match self {
Ok(x) => tcx.lift(x).map(Ok),
Err(e) => tcx.lift(e).map(Err),
}
}
}
impl<'tcx, T: Lift<'tcx>> Lift<'tcx> for Box<T> {
type Lifted = Box<T::Lifted>;
2020-10-16 21:59:49 +02:00
fn lift_to_tcx(self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {
2022-09-15 13:37:34 +00:00
Some(Box::new(tcx.lift(*self)?))
}
}
2020-10-16 21:59:49 +02:00
impl<'tcx, T: Lift<'tcx> + Clone> Lift<'tcx> for Rc<T> {
type Lifted = Rc<T::Lifted>;
2020-10-16 21:59:49 +02:00
fn lift_to_tcx(self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {
2022-09-15 13:37:34 +00:00
Some(Rc::new(tcx.lift(self.as_ref().clone())?))
}
}
2020-10-16 21:59:49 +02:00
impl<'tcx, T: Lift<'tcx> + Clone> Lift<'tcx> for Arc<T> {
2019-06-18 08:15:27 -04:00
type Lifted = Arc<T::Lifted>;
2020-10-16 21:59:49 +02:00
fn lift_to_tcx(self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {
2022-09-15 13:37:34 +00:00
Some(Arc::new(tcx.lift(self.as_ref().clone())?))
2015-09-06 21:51:58 +03:00
}
}
impl<'tcx, T: Lift<'tcx>> Lift<'tcx> for Vec<T> {
type Lifted = Vec<T::Lifted>;
2020-10-16 21:59:49 +02:00
fn lift_to_tcx(self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {
self.into_iter().map(|v| tcx.lift(v)).collect()
}
}
impl<'tcx, I: Idx, T: Lift<'tcx>> Lift<'tcx> for IndexVec<I, T> {
type Lifted = IndexVec<I, T::Lifted>;
2020-10-16 21:59:49 +02:00
fn lift_to_tcx(self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {
self.into_iter().map(|e| tcx.lift(e)).collect()
}
}
impl<'a, 'tcx> Lift<'tcx> for Term<'a> {
type Lifted = ty::Term<'tcx>;
fn lift_to_tcx(self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {
Some(
match self.unpack() {
TermKind::Ty(ty) => TermKind::Ty(tcx.lift(ty)?),
TermKind::Const(c) => TermKind::Const(tcx.lift(c)?),
}
.pack(),
)
}
}
impl<'a, 'tcx> Lift<'tcx> for ty::ParamEnv<'a> {
type Lifted = ty::ParamEnv<'tcx>;
2020-10-16 21:59:49 +02:00
fn lift_to_tcx(self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {
tcx.lift(self.caller_bounds())
.map(|caller_bounds| ty::ParamEnv::new(caller_bounds, self.reveal(), self.constness()))
}
}
2015-09-06 21:51:58 +03:00
///////////////////////////////////////////////////////////////////////////
// Traversal implementations.
2015-09-06 21:51:58 +03:00
/// AdtDefs are basically the same as a DefId.
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeFoldable<TyCtxt<'tcx>> for ty::AdtDef<'tcx> {
fn try_fold_with<F: FallibleTypeFolder<TyCtxt<'tcx>>>(
self,
_folder: &mut F,
) -> Result<Self, F::Error> {
Ok(self)
}
2022-06-17 12:09:23 +01:00
}
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeVisitable<TyCtxt<'tcx>> for ty::AdtDef<'tcx> {
fn visit_with<V: TypeVisitor<TyCtxt<'tcx>>>(
&self,
_visitor: &mut V,
) -> ControlFlow<V::BreakTy> {
ControlFlow::Continue(())
}
}
2023-02-22 02:18:40 +00:00
impl<'tcx, T: TypeFoldable<TyCtxt<'tcx>>> TypeFoldable<TyCtxt<'tcx>> for ty::Binder<'tcx, T> {
fn try_fold_with<F: FallibleTypeFolder<TyCtxt<'tcx>>>(
self,
folder: &mut F,
) -> Result<Self, F::Error> {
folder.try_fold_binder(self)
}
2022-06-17 12:09:23 +01:00
}
2023-02-22 02:18:40 +00:00
impl<'tcx, T: TypeVisitable<TyCtxt<'tcx>>> TypeVisitable<TyCtxt<'tcx>> for ty::Binder<'tcx, T> {
fn visit_with<V: TypeVisitor<TyCtxt<'tcx>>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
visitor.visit_binder(self)
}
2015-09-06 21:51:58 +03:00
}
2023-02-22 02:18:40 +00:00
impl<'tcx, T: TypeFoldable<TyCtxt<'tcx>>> TypeSuperFoldable<TyCtxt<'tcx>> for ty::Binder<'tcx, T> {
fn try_super_fold_with<F: FallibleTypeFolder<TyCtxt<'tcx>>>(
self,
folder: &mut F,
) -> Result<Self, F::Error> {
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
self.try_map_bound(|ty| ty.try_fold_with(folder))
}
2022-06-17 12:09:23 +01:00
}
2023-02-22 02:18:40 +00:00
impl<'tcx, T: TypeVisitable<TyCtxt<'tcx>>> TypeSuperVisitable<TyCtxt<'tcx>>
for ty::Binder<'tcx, T>
{
fn super_visit_with<V: TypeVisitor<TyCtxt<'tcx>>>(
&self,
visitor: &mut V,
) -> ControlFlow<V::BreakTy> {
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
self.as_ref().skip_binder().visit_with(visitor)
}
}
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeFoldable<TyCtxt<'tcx>> for &'tcx ty::List<ty::PolyExistentialPredicate<'tcx>> {
fn try_fold_with<F: FallibleTypeFolder<TyCtxt<'tcx>>>(
self,
folder: &mut F,
) -> Result<Self, F::Error> {
Rename many interner functions. (This is a large commit. The changes to `compiler/rustc_middle/src/ty/context.rs` are the most important ones.) The current naming scheme is a mess, with a mix of `_intern_`, `intern_` and `mk_` prefixes, with little consistency. In particular, in many cases it's easy to use an iterator interner when a (preferable) slice interner is available. The guiding principles of the new naming system: - No `_intern_` prefixes. - The `intern_` prefix is for internal operations. - The `mk_` prefix is for external operations. - For cases where there is a slice interner and an iterator interner, the former is `mk_foo` and the latter is `mk_foo_from_iter`. Also, `slice_interners!` and `direct_interners!` can now be `pub` or non-`pub`, which helps enforce the internal/external operations division. It's not perfect, but I think it's a clear improvement. The following lists show everything that was renamed. slice_interners - const_list - mk_const_list -> mk_const_list_from_iter - intern_const_list -> mk_const_list - substs - mk_substs -> mk_substs_from_iter - intern_substs -> mk_substs - check_substs -> check_and_mk_substs (this is a weird one) - canonical_var_infos - intern_canonical_var_infos -> mk_canonical_var_infos - poly_existential_predicates - mk_poly_existential_predicates -> mk_poly_existential_predicates_from_iter - intern_poly_existential_predicates -> mk_poly_existential_predicates - _intern_poly_existential_predicates -> intern_poly_existential_predicates - predicates - mk_predicates -> mk_predicates_from_iter - intern_predicates -> mk_predicates - _intern_predicates -> intern_predicates - projs - intern_projs -> mk_projs - place_elems - mk_place_elems -> mk_place_elems_from_iter - intern_place_elems -> mk_place_elems - bound_variable_kinds - mk_bound_variable_kinds -> mk_bound_variable_kinds_from_iter - intern_bound_variable_kinds -> mk_bound_variable_kinds direct_interners - region - intern_region (unchanged) - const - mk_const_internal -> intern_const - const_allocation - intern_const_alloc -> mk_const_alloc - layout - intern_layout -> mk_layout - adt_def - intern_adt_def -> mk_adt_def_from_data (unusual case, hard to avoid) - alloc_adt_def(!) -> mk_adt_def - external_constraints - intern_external_constraints -> mk_external_constraints Other - type_list - mk_type_list -> mk_type_list_from_iter - intern_type_list -> mk_type_list - tup - mk_tup -> mk_tup_from_iter - intern_tup -> mk_tup
2023-02-17 14:33:08 +11:00
ty::util::fold_list(self, folder, |tcx, v| tcx.mk_poly_existential_predicates(v))
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
}
2022-06-17 12:09:23 +01:00
}
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeFoldable<TyCtxt<'tcx>> for &'tcx ty::List<ty::Const<'tcx>> {
fn try_fold_with<F: FallibleTypeFolder<TyCtxt<'tcx>>>(
self,
folder: &mut F,
) -> Result<Self, F::Error> {
Rename many interner functions. (This is a large commit. The changes to `compiler/rustc_middle/src/ty/context.rs` are the most important ones.) The current naming scheme is a mess, with a mix of `_intern_`, `intern_` and `mk_` prefixes, with little consistency. In particular, in many cases it's easy to use an iterator interner when a (preferable) slice interner is available. The guiding principles of the new naming system: - No `_intern_` prefixes. - The `intern_` prefix is for internal operations. - The `mk_` prefix is for external operations. - For cases where there is a slice interner and an iterator interner, the former is `mk_foo` and the latter is `mk_foo_from_iter`. Also, `slice_interners!` and `direct_interners!` can now be `pub` or non-`pub`, which helps enforce the internal/external operations division. It's not perfect, but I think it's a clear improvement. The following lists show everything that was renamed. slice_interners - const_list - mk_const_list -> mk_const_list_from_iter - intern_const_list -> mk_const_list - substs - mk_substs -> mk_substs_from_iter - intern_substs -> mk_substs - check_substs -> check_and_mk_substs (this is a weird one) - canonical_var_infos - intern_canonical_var_infos -> mk_canonical_var_infos - poly_existential_predicates - mk_poly_existential_predicates -> mk_poly_existential_predicates_from_iter - intern_poly_existential_predicates -> mk_poly_existential_predicates - _intern_poly_existential_predicates -> intern_poly_existential_predicates - predicates - mk_predicates -> mk_predicates_from_iter - intern_predicates -> mk_predicates - _intern_predicates -> intern_predicates - projs - intern_projs -> mk_projs - place_elems - mk_place_elems -> mk_place_elems_from_iter - intern_place_elems -> mk_place_elems - bound_variable_kinds - mk_bound_variable_kinds -> mk_bound_variable_kinds_from_iter - intern_bound_variable_kinds -> mk_bound_variable_kinds direct_interners - region - intern_region (unchanged) - const - mk_const_internal -> intern_const - const_allocation - intern_const_alloc -> mk_const_alloc - layout - intern_layout -> mk_layout - adt_def - intern_adt_def -> mk_adt_def_from_data (unusual case, hard to avoid) - alloc_adt_def(!) -> mk_adt_def - external_constraints - intern_external_constraints -> mk_external_constraints Other - type_list - mk_type_list -> mk_type_list_from_iter - intern_type_list -> mk_type_list - tup - mk_tup -> mk_tup_from_iter - intern_tup -> mk_tup
2023-02-17 14:33:08 +11:00
ty::util::fold_list(self, folder, |tcx, v| tcx.mk_const_list(v))
}
}
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeFoldable<TyCtxt<'tcx>> for &'tcx ty::List<ProjectionKind> {
fn try_fold_with<F: FallibleTypeFolder<TyCtxt<'tcx>>>(
self,
folder: &mut F,
) -> Result<Self, F::Error> {
Rename many interner functions. (This is a large commit. The changes to `compiler/rustc_middle/src/ty/context.rs` are the most important ones.) The current naming scheme is a mess, with a mix of `_intern_`, `intern_` and `mk_` prefixes, with little consistency. In particular, in many cases it's easy to use an iterator interner when a (preferable) slice interner is available. The guiding principles of the new naming system: - No `_intern_` prefixes. - The `intern_` prefix is for internal operations. - The `mk_` prefix is for external operations. - For cases where there is a slice interner and an iterator interner, the former is `mk_foo` and the latter is `mk_foo_from_iter`. Also, `slice_interners!` and `direct_interners!` can now be `pub` or non-`pub`, which helps enforce the internal/external operations division. It's not perfect, but I think it's a clear improvement. The following lists show everything that was renamed. slice_interners - const_list - mk_const_list -> mk_const_list_from_iter - intern_const_list -> mk_const_list - substs - mk_substs -> mk_substs_from_iter - intern_substs -> mk_substs - check_substs -> check_and_mk_substs (this is a weird one) - canonical_var_infos - intern_canonical_var_infos -> mk_canonical_var_infos - poly_existential_predicates - mk_poly_existential_predicates -> mk_poly_existential_predicates_from_iter - intern_poly_existential_predicates -> mk_poly_existential_predicates - _intern_poly_existential_predicates -> intern_poly_existential_predicates - predicates - mk_predicates -> mk_predicates_from_iter - intern_predicates -> mk_predicates - _intern_predicates -> intern_predicates - projs - intern_projs -> mk_projs - place_elems - mk_place_elems -> mk_place_elems_from_iter - intern_place_elems -> mk_place_elems - bound_variable_kinds - mk_bound_variable_kinds -> mk_bound_variable_kinds_from_iter - intern_bound_variable_kinds -> mk_bound_variable_kinds direct_interners - region - intern_region (unchanged) - const - mk_const_internal -> intern_const - const_allocation - intern_const_alloc -> mk_const_alloc - layout - intern_layout -> mk_layout - adt_def - intern_adt_def -> mk_adt_def_from_data (unusual case, hard to avoid) - alloc_adt_def(!) -> mk_adt_def - external_constraints - intern_external_constraints -> mk_external_constraints Other - type_list - mk_type_list -> mk_type_list_from_iter - intern_type_list -> mk_type_list - tup - mk_tup -> mk_tup_from_iter - intern_tup -> mk_tup
2023-02-17 14:33:08 +11:00
ty::util::fold_list(self, folder, |tcx, v| tcx.mk_projs(v))
}
2022-06-17 12:09:23 +01:00
}
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeFoldable<TyCtxt<'tcx>> for Ty<'tcx> {
fn try_fold_with<F: FallibleTypeFolder<TyCtxt<'tcx>>>(
self,
folder: &mut F,
) -> Result<Self, F::Error> {
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
folder.try_fold_ty(self)
}
2022-06-17 12:09:23 +01:00
}
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeVisitable<TyCtxt<'tcx>> for Ty<'tcx> {
fn visit_with<V: TypeVisitor<TyCtxt<'tcx>>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
visitor.visit_ty(*self)
}
}
impl<'tcx> TypeSuperFoldable<TyCtxt<'tcx>> for Ty<'tcx> {
2023-02-22 02:18:40 +00:00
fn try_super_fold_with<F: FallibleTypeFolder<TyCtxt<'tcx>>>(
self,
folder: &mut F,
) -> Result<Self, F::Error> {
2020-10-24 09:27:15 +02:00
let kind = match *self.kind() {
ty::RawPtr(tm) => ty::RawPtr(tm.try_fold_with(folder)?),
ty::Array(typ, sz) => ty::Array(typ.try_fold_with(folder)?, sz.try_fold_with(folder)?),
ty::Slice(typ) => ty::Slice(typ.try_fold_with(folder)?),
ty::Adt(tid, substs) => ty::Adt(tid, substs.try_fold_with(folder)?),
ty::Dynamic(trait_ty, region, representation) => ty::Dynamic(
trait_ty.try_fold_with(folder)?,
region.try_fold_with(folder)?,
representation,
),
ty::Tuple(ts) => ty::Tuple(ts.try_fold_with(folder)?),
ty::FnDef(def_id, substs) => ty::FnDef(def_id, substs.try_fold_with(folder)?),
ty::FnPtr(f) => ty::FnPtr(f.try_fold_with(folder)?),
ty::Ref(r, ty, mutbl) => {
ty::Ref(r.try_fold_with(folder)?, ty.try_fold_with(folder)?, mutbl)
}
ty::Generator(did, substs, movability) => {
ty::Generator(did, substs.try_fold_with(folder)?, movability)
2017-07-05 14:57:26 -07:00
}
ty::GeneratorWitness(types) => ty::GeneratorWitness(types.try_fold_with(folder)?),
2022-10-01 14:56:24 +02:00
ty::GeneratorWitnessMIR(did, substs) => {
ty::GeneratorWitnessMIR(did, substs.try_fold_with(folder)?)
}
ty::Closure(did, substs) => ty::Closure(did, substs.try_fold_with(folder)?),
2022-11-27 17:52:17 +00:00
ty::Alias(kind, data) => ty::Alias(kind, data.try_fold_with(folder)?),
2018-10-22 20:37:56 +02:00
ty::Bool
| ty::Char
| ty::Str
| ty::Int(_)
| ty::Uint(_)
| ty::Float(_)
| ty::Error(_)
2018-10-22 20:37:56 +02:00
| ty::Infer(_)
| ty::Param(..)
| ty::Bound(..)
| ty::Placeholder(..)
2018-10-22 20:37:56 +02:00
| ty::Never
| ty::Foreign(..) => return Ok(self),
};
Ok(if *self.kind() == kind { self } else { folder.interner().mk_ty(kind) })
}
2022-06-17 12:09:23 +01:00
}
impl<'tcx> TypeSuperVisitable<TyCtxt<'tcx>> for Ty<'tcx> {
2023-02-22 02:18:40 +00:00
fn super_visit_with<V: TypeVisitor<TyCtxt<'tcx>>>(
&self,
visitor: &mut V,
) -> ControlFlow<V::BreakTy> {
2020-08-03 00:49:11 +02:00
match self.kind() {
ty::RawPtr(ref tm) => tm.visit_with(visitor),
ty::Array(typ, sz) => {
typ.visit_with(visitor)?;
sz.visit_with(visitor)
}
ty::Slice(typ) => typ.visit_with(visitor),
ty::Adt(_, substs) => substs.visit_with(visitor),
ty::Dynamic(ref trait_ty, ref reg, _) => {
trait_ty.visit_with(visitor)?;
reg.visit_with(visitor)
2019-12-22 17:42:04 -05:00
}
ty::Tuple(ts) => ts.visit_with(visitor),
ty::FnDef(_, substs) => substs.visit_with(visitor),
ty::FnPtr(ref f) => f.visit_with(visitor),
ty::Ref(r, ty, _) => {
r.visit_with(visitor)?;
ty.visit_with(visitor)
}
ty::Generator(_did, ref substs, _) => substs.visit_with(visitor),
ty::GeneratorWitness(ref types) => types.visit_with(visitor),
2022-10-01 14:56:24 +02:00
ty::GeneratorWitnessMIR(_did, ref substs) => substs.visit_with(visitor),
ty::Closure(_did, ref substs) => substs.visit_with(visitor),
2022-11-27 17:52:17 +00:00
ty::Alias(_, ref data) => data.visit_with(visitor),
2018-10-22 20:37:56 +02:00
ty::Bool
| ty::Char
| ty::Str
| ty::Int(_)
| ty::Uint(_)
| ty::Float(_)
| ty::Error(_)
2018-10-22 20:37:56 +02:00
| ty::Infer(_)
| ty::Bound(..)
| ty::Placeholder(..)
2018-10-22 20:37:56 +02:00
| ty::Param(..)
| ty::Never
| ty::Foreign(..) => ControlFlow::Continue(()),
}
}
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
}
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeFoldable<TyCtxt<'tcx>> for ty::Region<'tcx> {
fn try_fold_with<F: FallibleTypeFolder<TyCtxt<'tcx>>>(
self,
folder: &mut F,
) -> Result<Self, F::Error> {
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
folder.try_fold_region(self)
}
2022-06-17 12:09:23 +01:00
}
2015-09-06 21:51:58 +03:00
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeVisitable<TyCtxt<'tcx>> for ty::Region<'tcx> {
fn visit_with<V: TypeVisitor<TyCtxt<'tcx>>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
visitor.visit_region(*self)
2015-09-06 21:51:58 +03:00
}
}
impl<'tcx> TypeSuperFoldable<TyCtxt<'tcx>> for ty::Region<'tcx> {
2023-02-22 02:18:40 +00:00
fn try_super_fold_with<F: FallibleTypeFolder<TyCtxt<'tcx>>>(
self,
_folder: &mut F,
) -> Result<Self, F::Error> {
Ok(self)
}
2022-06-17 12:09:23 +01:00
}
impl<'tcx> TypeSuperVisitable<TyCtxt<'tcx>> for ty::Region<'tcx> {
2023-02-22 02:18:40 +00:00
fn super_visit_with<V: TypeVisitor<TyCtxt<'tcx>>>(
&self,
_visitor: &mut V,
) -> ControlFlow<V::BreakTy> {
ControlFlow::Continue(())
}
2015-09-06 21:51:58 +03:00
}
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeFoldable<TyCtxt<'tcx>> for ty::Predicate<'tcx> {
fn try_fold_with<F: FallibleTypeFolder<TyCtxt<'tcx>>>(
self,
folder: &mut F,
) -> Result<Self, F::Error> {
folder.try_fold_predicate(self)
2021-07-19 12:13:25 +02:00
}
2022-06-17 12:09:23 +01:00
}
2021-07-19 12:13:25 +02:00
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeVisitable<TyCtxt<'tcx>> for ty::Predicate<'tcx> {
fn visit_with<V: TypeVisitor<TyCtxt<'tcx>>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
visitor.visit_predicate(*self)
}
}
impl<'tcx> TypeSuperFoldable<TyCtxt<'tcx>> for ty::Predicate<'tcx> {
2023-02-22 02:18:40 +00:00
fn try_super_fold_with<F: FallibleTypeFolder<TyCtxt<'tcx>>>(
self,
folder: &mut F,
) -> Result<Self, F::Error> {
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
let new = self.kind().try_fold_with(folder)?;
Ok(folder.interner().reuse_or_mk_predicate(self, new))
2017-05-23 04:19:47 -04:00
}
2022-06-17 12:09:23 +01:00
}
2017-05-23 04:19:47 -04:00
impl<'tcx> TypeSuperVisitable<TyCtxt<'tcx>> for ty::Predicate<'tcx> {
2023-02-22 02:18:40 +00:00
fn super_visit_with<V: TypeVisitor<TyCtxt<'tcx>>>(
&self,
visitor: &mut V,
) -> ControlFlow<V::BreakTy> {
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
self.kind().visit_with(visitor)
}
}
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeFoldable<TyCtxt<'tcx>> for &'tcx ty::List<ty::Predicate<'tcx>> {
fn try_fold_with<F: FallibleTypeFolder<TyCtxt<'tcx>>>(
self,
folder: &mut F,
) -> Result<Self, F::Error> {
Rename many interner functions. (This is a large commit. The changes to `compiler/rustc_middle/src/ty/context.rs` are the most important ones.) The current naming scheme is a mess, with a mix of `_intern_`, `intern_` and `mk_` prefixes, with little consistency. In particular, in many cases it's easy to use an iterator interner when a (preferable) slice interner is available. The guiding principles of the new naming system: - No `_intern_` prefixes. - The `intern_` prefix is for internal operations. - The `mk_` prefix is for external operations. - For cases where there is a slice interner and an iterator interner, the former is `mk_foo` and the latter is `mk_foo_from_iter`. Also, `slice_interners!` and `direct_interners!` can now be `pub` or non-`pub`, which helps enforce the internal/external operations division. It's not perfect, but I think it's a clear improvement. The following lists show everything that was renamed. slice_interners - const_list - mk_const_list -> mk_const_list_from_iter - intern_const_list -> mk_const_list - substs - mk_substs -> mk_substs_from_iter - intern_substs -> mk_substs - check_substs -> check_and_mk_substs (this is a weird one) - canonical_var_infos - intern_canonical_var_infos -> mk_canonical_var_infos - poly_existential_predicates - mk_poly_existential_predicates -> mk_poly_existential_predicates_from_iter - intern_poly_existential_predicates -> mk_poly_existential_predicates - _intern_poly_existential_predicates -> intern_poly_existential_predicates - predicates - mk_predicates -> mk_predicates_from_iter - intern_predicates -> mk_predicates - _intern_predicates -> intern_predicates - projs - intern_projs -> mk_projs - place_elems - mk_place_elems -> mk_place_elems_from_iter - intern_place_elems -> mk_place_elems - bound_variable_kinds - mk_bound_variable_kinds -> mk_bound_variable_kinds_from_iter - intern_bound_variable_kinds -> mk_bound_variable_kinds direct_interners - region - intern_region (unchanged) - const - mk_const_internal -> intern_const - const_allocation - intern_const_alloc -> mk_const_alloc - layout - intern_layout -> mk_layout - adt_def - intern_adt_def -> mk_adt_def_from_data (unusual case, hard to avoid) - alloc_adt_def(!) -> mk_adt_def - external_constraints - intern_external_constraints -> mk_external_constraints Other - type_list - mk_type_list -> mk_type_list_from_iter - intern_type_list -> mk_type_list - tup - mk_tup -> mk_tup_from_iter - intern_tup -> mk_tup
2023-02-17 14:33:08 +11:00
ty::util::fold_list(self, folder, |tcx, v| tcx.mk_predicates(v))
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
}
2022-06-17 12:09:23 +01:00
}
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeFoldable<TyCtxt<'tcx>> for ty::Const<'tcx> {
fn try_fold_with<F: FallibleTypeFolder<TyCtxt<'tcx>>>(
self,
folder: &mut F,
) -> Result<Self, F::Error> {
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
folder.try_fold_const(self)
}
2022-06-17 12:09:23 +01:00
}
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeVisitable<TyCtxt<'tcx>> for ty::Const<'tcx> {
fn visit_with<V: TypeVisitor<TyCtxt<'tcx>>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
Folding revamp. This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-02 11:38:15 +10:00
visitor.visit_const(*self)
}
}
impl<'tcx> TypeSuperFoldable<TyCtxt<'tcx>> for ty::Const<'tcx> {
2023-02-22 02:18:40 +00:00
fn try_super_fold_with<F: FallibleTypeFolder<TyCtxt<'tcx>>>(
self,
folder: &mut F,
) -> Result<Self, F::Error> {
let ty = self.ty().try_fold_with(folder)?;
let kind = self.kind().try_fold_with(folder)?;
if ty != self.ty() || kind != self.kind() {
Ok(folder.interner().mk_const(kind, ty))
2020-05-31 17:16:44 +02:00
} else {
Ok(self)
2020-05-31 17:16:44 +02:00
}
}
2022-06-17 12:09:23 +01:00
}
impl<'tcx> TypeSuperVisitable<TyCtxt<'tcx>> for ty::Const<'tcx> {
2023-02-22 02:18:40 +00:00
fn super_visit_with<V: TypeVisitor<TyCtxt<'tcx>>>(
&self,
visitor: &mut V,
) -> ControlFlow<V::BreakTy> {
self.ty().visit_with(visitor)?;
self.kind().visit_with(visitor)
}
}
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeFoldable<TyCtxt<'tcx>> for InferConst<'tcx> {
fn try_fold_with<F: FallibleTypeFolder<TyCtxt<'tcx>>>(
self,
_folder: &mut F,
) -> Result<Self, F::Error> {
Ok(self)
}
2022-06-17 12:09:23 +01:00
}
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeVisitable<TyCtxt<'tcx>> for InferConst<'tcx> {
fn visit_with<V: TypeVisitor<TyCtxt<'tcx>>>(
&self,
_visitor: &mut V,
) -> ControlFlow<V::BreakTy> {
ControlFlow::Continue(())
}
}
impl<'tcx> TypeSuperVisitable<TyCtxt<'tcx>> for ty::UnevaluatedConst<'tcx> {
2023-02-22 02:18:40 +00:00
fn super_visit_with<V: TypeVisitor<TyCtxt<'tcx>>>(
&self,
visitor: &mut V,
) -> ControlFlow<V::BreakTy> {
self.substs.visit_with(visitor)
}
}
2023-02-22 02:18:40 +00:00
impl<'tcx> TypeVisitable<TyCtxt<'tcx>> for TyAndLayout<'tcx, Ty<'tcx>> {
fn visit_with<V: TypeVisitor<TyCtxt<'tcx>>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
visitor.visit_ty(self.ty)
}
}