2017-11-11 13:04:36 -05:00
|
|
|
//! This module contains implements of the `Lift` and `TypeFoldable`
|
|
|
|
//! traits for various types in the Rust compiler. Most are written by
|
2019-11-15 18:19:52 +01:00
|
|
|
//! hand, though we've recently added some macros and proc-macros to help with the tedium.
|
2017-11-11 13:04:36 -05:00
|
|
|
|
2019-05-17 02:20:14 +01:00
|
|
|
use crate::mir::interpret;
|
2022-08-23 01:13:07 -04:00
|
|
|
use crate::mir::{Field, ProjectionKind};
|
2023-02-09 14:02:47 +00:00
|
|
|
use crate::ty::fold::{ir::TypeSuperFoldable, FallibleTypeFolder, TypeFoldable};
|
2020-09-02 10:40:56 +03:00
|
|
|
use crate::ty::print::{with_no_trimmed_paths, FmtPrinter, Printer};
|
2023-02-09 14:02:47 +00:00
|
|
|
use crate::ty::visit::{ir::TypeSuperVisitable, TypeVisitable, TypeVisitor};
|
|
|
|
use crate::ty::{self, ir, AliasTy, InferConst, Lift, Term, TermKind, Ty, TyCtxt};
|
2020-10-24 02:21:18 +02:00
|
|
|
use rustc_data_structures::functor::IdFunctor;
|
2020-01-05 02:37:57 +01:00
|
|
|
use rustc_hir::def::Namespace;
|
2019-09-26 05:38:33 +00:00
|
|
|
use rustc_index::vec::{Idx, IndexVec};
|
2023-01-22 17:06:28 -05:00
|
|
|
use rustc_target::abi::TyAndLayout;
|
2015-09-06 21:51:58 +03:00
|
|
|
|
2019-01-19 06:33:44 +02:00
|
|
|
use std::fmt;
|
2021-11-29 12:55:00 +00:00
|
|
|
use std::mem::ManuallyDrop;
|
2020-10-21 14:22:44 +02:00
|
|
|
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
|
|
|
|
2019-01-19 06:33:44 +02:00
|
|
|
impl fmt::Debug for ty::TraitDef {
|
|
|
|
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
|
2019-01-25 12:11:50 +02:00
|
|
|
ty::tls::with(|tcx| {
|
2022-02-18 16:15:29 -05:00
|
|
|
with_no_trimmed_paths!({
|
|
|
|
f.write_str(
|
|
|
|
&FmtPrinter::new(tcx, Namespace::TypeNS)
|
|
|
|
.print_def_path(self.def_id, &[])?
|
|
|
|
.into_buffer(),
|
|
|
|
)
|
|
|
|
})
|
2019-01-19 06:33:44 +02:00
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-03-05 07:28:41 +11:00
|
|
|
impl<'tcx> fmt::Debug for ty::AdtDef<'tcx> {
|
2019-01-19 06:33:44 +02:00
|
|
|
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
|
2019-01-25 12:11:50 +02:00
|
|
|
ty::tls::with(|tcx| {
|
2022-02-18 16:15:29 -05:00
|
|
|
with_no_trimmed_paths!({
|
|
|
|
f.write_str(
|
|
|
|
&FmtPrinter::new(tcx, Namespace::TypeNS)
|
2022-03-05 07:28:41 +11:00
|
|
|
.print_def_path(self.did(), &[])?
|
2022-02-18 16:15:29 -05:00
|
|
|
.into_buffer(),
|
|
|
|
)
|
|
|
|
})
|
2019-01-19 06:33:44 +02:00
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl fmt::Debug for ty::UpvarId {
|
|
|
|
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
|
2019-06-19 15:44:51 +02:00
|
|
|
let name = ty::tls::with(|tcx| tcx.hir().name(self.var_path.hir_id));
|
2019-01-19 06:33:44 +02:00
|
|
|
write!(f, "UpvarId({:?};`{}`;{:?})", self.var_path.hir_id, name, self.closure_expr_id)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-12-15 19:32:30 -05:00
|
|
|
impl<'tcx> fmt::Debug for ty::ExistentialTraitRef<'tcx> {
|
2019-01-19 06:33:44 +02:00
|
|
|
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
|
2022-02-16 13:04:48 -05:00
|
|
|
with_no_trimmed_paths!(fmt::Display::fmt(self, f))
|
2019-01-19 06:33:44 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-12-15 19:32:30 -05:00
|
|
|
impl<'tcx> fmt::Debug for ty::adjustment::Adjustment<'tcx> {
|
2019-01-19 06:33:44 +02:00
|
|
|
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
|
|
|
|
write!(f, "{:?} -> {}", self.kind, self.target)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-12-18 13:24:55 -05:00
|
|
|
impl fmt::Debug for ty::BoundRegionKind {
|
2019-01-19 06:33:44 +02:00
|
|
|
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
|
|
|
|
match *self {
|
2022-10-17 22:08:15 -04:00
|
|
|
ty::BrAnon(n, span) => write!(f, "BrAnon({n:?}, {span:?})"),
|
2019-01-19 06:33:44 +02:00
|
|
|
ty::BrNamed(did, name) => {
|
2022-04-15 19:27:53 +02:00
|
|
|
if did.is_crate_root() {
|
2019-11-30 17:29:56 +02:00
|
|
|
write!(f, "BrNamed({})", name)
|
|
|
|
} else {
|
|
|
|
write!(f, "BrNamed({:?}, {})", did, name)
|
|
|
|
}
|
2019-01-19 06:33:44 +02:00
|
|
|
}
|
|
|
|
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)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-12-15 19:32:30 -05:00
|
|
|
impl<'tcx> fmt::Debug for ty::FnSig<'tcx> {
|
2019-01-19 06:33:44 +02:00
|
|
|
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)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-12-15 19:32:30 -05:00
|
|
|
impl<'tcx> fmt::Debug for ty::TraitRef<'tcx> {
|
2019-01-19 06:33:44 +02:00
|
|
|
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
|
2022-02-16 13:04:48 -05:00
|
|
|
with_no_trimmed_paths!(fmt::Display::fmt(self, f))
|
2019-01-19 06:33:44 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-12-15 19:32:30 -05:00
|
|
|
impl<'tcx> fmt::Debug for Ty<'tcx> {
|
2019-01-19 06:33:44 +02:00
|
|
|
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
|
2022-02-16 13:04:48 -05:00
|
|
|
with_no_trimmed_paths!(fmt::Display::fmt(self, f))
|
2019-01-19 06:33:44 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl fmt::Debug for ty::ParamTy {
|
|
|
|
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
|
2019-05-06 13:12:04 +01:00
|
|
|
write!(f, "{}/#{}", self.name, self.index)
|
2019-01-19 06:33:44 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl fmt::Debug for ty::ParamConst {
|
|
|
|
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
|
|
|
|
write!(f, "{}/#{}", self.name, self.index)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-12-15 19:32:30 -05:00
|
|
|
impl<'tcx> fmt::Debug for ty::TraitPredicate<'tcx> {
|
2019-01-19 06:33:44 +02:00
|
|
|
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)
|
2019-01-19 06:33:44 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-12-15 19:32:30 -05:00
|
|
|
impl<'tcx> fmt::Debug for ty::ProjectionPredicate<'tcx> {
|
2019-01-19 06:33:44 +02:00
|
|
|
fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
|
2022-01-08 09:28:12 +00:00
|
|
|
write!(f, "ProjectionPredicate({:?}, {:?})", self.projection_ty, self.term)
|
2019-01-19 06:33:44 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-12-15 19:32:30 -05:00
|
|
|
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 {
|
|
|
|
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),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-12-15 19:32:30 -05:00
|
|
|
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) => {
|
2020-05-11 21:09:57 +02:00
|
|
|
write!(f, "ObjectSafe({:?})", trait_def_id)
|
|
|
|
}
|
2021-01-07 11:20:28 -05:00
|
|
|
ty::PredicateKind::ClosureKind(closure_def_id, closure_substs, kind) => {
|
2019-01-19 06:33:44 +02:00
|
|
|
write!(f, "ClosureKind({:?}, {:?}, {:?})", closure_def_id, closure_substs, kind)
|
|
|
|
}
|
2022-10-18 16:09:04 +02:00
|
|
|
ty::PredicateKind::ConstEvaluatable(ct) => {
|
|
|
|
write!(f, "ConstEvaluatable({ct:?})")
|
2019-01-19 06:33:44 +02:00
|
|
|
}
|
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)
|
|
|
|
}
|
2022-11-02 15:10:05 +00:00
|
|
|
ty::PredicateKind::Ambiguous => write!(f, "Ambiguous"),
|
2023-02-10 13:43:29 +00:00
|
|
|
ty::PredicateKind::AliasEq(t1, t2) => write!(f, "AliasEq({t1:?}, {t2:?})"),
|
2019-01-19 06:33:44 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-01-17 14:06:12 +01:00
|
|
|
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()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-11-11 13:04:36 -05:00
|
|
|
///////////////////////////////////////////////////////////////////////////
|
|
|
|
// Atomic structs
|
|
|
|
//
|
|
|
|
// For things that don't carry any arena-allocated data (and are
|
|
|
|
// copy...), just add them to this list.
|
|
|
|
|
2022-06-17 11:05:17 +01:00
|
|
|
TrivialTypeTraversalAndLiftImpls! {
|
2017-11-11 13:04:36 -05:00
|
|
|
(),
|
2018-02-09 10:34:23 -05:00
|
|
|
bool,
|
|
|
|
usize,
|
2020-03-31 18:16:47 +02:00
|
|
|
::rustc_target::abi::VariantIdx,
|
2022-09-11 14:42:43 +02:00
|
|
|
u16,
|
2020-08-15 04:42:13 -07:00
|
|
|
u32,
|
2018-02-09 10:34:23 -05:00
|
|
|
u64,
|
2018-11-26 17:30:19 +01:00
|
|
|
String,
|
2019-02-05 11:20:45 -06:00
|
|
|
crate::middle::region::Scope,
|
2020-12-12 15:25:55 +01:00
|
|
|
crate::ty::FloatTy,
|
2020-04-27 23:26:11 +05:30
|
|
|
::rustc_ast::InlineAsmOptions,
|
|
|
|
::rustc_ast::InlineAsmTemplatePiece,
|
|
|
|
::rustc_ast::NodeId,
|
2019-12-31 20:15:40 +03:00
|
|
|
::rustc_span::symbol::Symbol,
|
2020-01-05 02:37:57 +01:00
|
|
|
::rustc_hir::def::Res,
|
|
|
|
::rustc_hir::def_id::DefId,
|
2020-07-08 01:03:19 +02:00
|
|
|
::rustc_hir::def_id::LocalDefId,
|
2020-08-02 15:42:08 +02:00
|
|
|
::rustc_hir::HirId,
|
2020-01-05 02:37:57 +01:00
|
|
|
::rustc_hir::MatchSource,
|
|
|
|
::rustc_hir::Mutability,
|
|
|
|
::rustc_hir::Unsafety,
|
2020-02-14 18:17:50 +00:00
|
|
|
::rustc_target::asm::InlineAsmRegOrRegClass,
|
2018-04-25 19:30:39 +03:00
|
|
|
::rustc_target::spec::abi::Abi,
|
2020-08-15 04:42:13 -07:00
|
|
|
crate::mir::coverage::ExpressionOperandId,
|
|
|
|
crate::mir::coverage::CounterValueReference,
|
2020-10-05 16:36:10 -07:00
|
|
|
crate::mir::coverage::InjectedExpressionId,
|
2020-08-15 04:42:13 -07:00
|
|
|
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,
|
2020-12-18 13:24:55 -05:00
|
|
|
// Including `BoundRegionKind` is a *bit* dubious, but direct
|
2018-02-09 10:34:23 -05:00
|
|
|
// 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`.
|
2020-12-18 13:24:55 -05:00
|
|
|
crate::ty::BoundRegionKind,
|
2020-08-02 15:42:08 +02:00
|
|
|
crate::ty::AssocItem,
|
2022-07-24 19:33:26 +00:00
|
|
|
crate::ty::AssocKind,
|
2023-01-13 23:53:28 +00:00
|
|
|
crate::ty::AliasKind,
|
2020-12-18 13:24:55 -05:00
|
|
|
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,
|
2018-12-07 17:40:23 +02:00
|
|
|
crate::ty::FreeRegion,
|
|
|
|
crate::ty::InferTy,
|
2019-02-05 11:20:45 -06:00
|
|
|
crate::ty::IntVarValue,
|
2019-02-20 01:18:43 +00:00
|
|
|
crate::ty::ParamConst,
|
2019-02-05 11:20:45 -06:00
|
|
|
crate::ty::ParamTy,
|
2019-04-16 17:36:41 +05:30
|
|
|
crate::ty::adjustment::PointerCast,
|
2018-12-10 17:36:24 +02:00
|
|
|
crate::ty::RegionVid,
|
2019-02-05 11:20:45 -06:00
|
|
|
crate::ty::UniverseIndex,
|
|
|
|
crate::ty::Variance,
|
2019-12-31 20:15:40 +03:00
|
|
|
::rustc_span::Span,
|
2022-01-23 12:34:26 -06:00
|
|
|
::rustc_errors::ErrorGuaranteed,
|
2022-09-08 09:04:52 +00:00
|
|
|
Field,
|
|
|
|
interpret::Scalar,
|
|
|
|
rustc_target::abi::Size,
|
2022-09-15 15:05:03 +00:00
|
|
|
rustc_type_ir::DebruijnIndex,
|
|
|
|
ty::BoundVar,
|
|
|
|
ty::Placeholder<ty::BoundVar>,
|
|
|
|
}
|
|
|
|
|
|
|
|
TrivialTypeTraversalAndLiftImpls! {
|
|
|
|
for<'tcx> {
|
|
|
|
ty::ValTree<'tcx>,
|
|
|
|
}
|
2017-11-11 13:04:36 -05:00
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2016-04-29 06:00:23 +03: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,
|
|
|
|
})
|
2016-04-29 06:00:23 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
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),
|
2016-04-29 06:00:23 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-08-07 08:08:53 +03:00
|
|
|
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)?))
|
2017-08-07 08:08:53 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-16 21:59:49 +02:00
|
|
|
impl<'tcx, T: Lift<'tcx> + Clone> Lift<'tcx> for Rc<T> {
|
2019-06-05 05:58:08 -04:00
|
|
|
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())?))
|
2019-06-05 05:58:08 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
}
|
2016-05-02 18:07:47 +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()
|
2016-05-02 18:07:47 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-11-11 13:04:36 -05:00
|
|
|
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()
|
2017-11-11 13:04:36 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-01-08 09:28:12 +00:00
|
|
|
impl<'a, 'tcx> Lift<'tcx> for Term<'a> {
|
|
|
|
type Lifted = ty::Term<'tcx>;
|
|
|
|
fn lift_to_tcx(self, tcx: TyCtxt<'tcx>) -> Option<Self::Lifted> {
|
2022-09-05 14:03:53 +10:00
|
|
|
Some(
|
|
|
|
match self.unpack() {
|
|
|
|
TermKind::Ty(ty) => TermKind::Ty(tcx.lift(ty)?),
|
|
|
|
TermKind::Const(c) => TermKind::Const(tcx.lift(c)?),
|
|
|
|
}
|
|
|
|
.pack(),
|
|
|
|
)
|
2022-01-08 09:28:12 +00:00
|
|
|
}
|
|
|
|
}
|
2017-08-07 08:08:53 +03:00
|
|
|
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())
|
2021-12-12 12:34:46 +08:00
|
|
|
.map(|caller_bounds| ty::ParamEnv::new(caller_bounds, self.reveal(), self.constness()))
|
2017-08-07 08:08:53 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-09-06 21:51:58 +03:00
|
|
|
///////////////////////////////////////////////////////////////////////////
|
|
|
|
// TypeFoldable implementations.
|
|
|
|
|
2018-02-09 10:34:23 -05:00
|
|
|
/// AdtDefs are basically the same as a DefId.
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeFoldable<'tcx> for ty::AdtDef<'tcx> {
|
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
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(self, _folder: &mut F) -> Result<Self, F::Error> {
|
2021-05-19 13:34:54 +02:00
|
|
|
Ok(self)
|
2018-02-09 10:34:23 -05:00
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2018-02-09 10:34:23 -05:00
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeVisitable<'tcx> for ty::AdtDef<'tcx> {
|
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
|
|
|
fn visit_with<V: TypeVisitor<'tcx>>(&self, _visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
2023-01-17 23:17:13 -08:00
|
|
|
ControlFlow::Continue(())
|
2018-02-09 10:34:23 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeFoldable<'tcx>, U: TypeFoldable<'tcx>> ir::TypeFoldable<'tcx> for (T, U) {
|
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
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(
|
2021-12-01 00:55:57 +00:00
|
|
|
self,
|
|
|
|
folder: &mut F,
|
|
|
|
) -> Result<(T, U), F::Error> {
|
|
|
|
Ok((self.0.try_fold_with(folder)?, self.1.try_fold_with(folder)?))
|
2015-09-06 21:51:58 +03:00
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2015-11-18 09:38:57 +00:00
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeVisitable<'tcx>, U: TypeVisitable<'tcx>> ir::TypeVisitable<'tcx> for (T, U) {
|
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
|
|
|
fn visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
2020-10-21 14:22:44 +02:00
|
|
|
self.0.visit_with(visitor)?;
|
|
|
|
self.1.visit_with(visitor)
|
2015-11-18 09:38:57 +00:00
|
|
|
}
|
2015-09-06 21:51:58 +03:00
|
|
|
}
|
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, A: TypeFoldable<'tcx>, B: TypeFoldable<'tcx>, C: TypeFoldable<'tcx>>
|
|
|
|
ir::TypeFoldable<'tcx> for (A, B, C)
|
2020-07-08 01:03:19 +02: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
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(
|
2021-12-01 00:55:57 +00:00
|
|
|
self,
|
|
|
|
folder: &mut F,
|
|
|
|
) -> Result<(A, B, C), F::Error> {
|
|
|
|
Ok((
|
|
|
|
self.0.try_fold_with(folder)?,
|
|
|
|
self.1.try_fold_with(folder)?,
|
|
|
|
self.2.try_fold_with(folder)?,
|
|
|
|
))
|
2020-07-08 01:03:19 +02:00
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2020-07-08 01:03:19 +02:00
|
|
|
|
2022-06-17 12:09:23 +01:00
|
|
|
impl<'tcx, A: TypeVisitable<'tcx>, B: TypeVisitable<'tcx>, C: TypeVisitable<'tcx>>
|
2023-02-09 14:02:47 +00:00
|
|
|
ir::TypeVisitable<'tcx> for (A, B, C)
|
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
|
|
|
fn visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
2020-10-21 14:22:44 +02:00
|
|
|
self.0.visit_with(visitor)?;
|
|
|
|
self.1.visit_with(visitor)?;
|
|
|
|
self.2.visit_with(visitor)
|
2020-07-08 01:03:19 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-06-17 11:05:17 +01:00
|
|
|
EnumTypeTraversalImpl! {
|
2018-02-09 10:34:23 -05:00
|
|
|
impl<'tcx, T> TypeFoldable<'tcx> for Option<T> {
|
|
|
|
(Some)(a),
|
|
|
|
(None),
|
|
|
|
} where T: TypeFoldable<'tcx>
|
2015-09-06 21:51:58 +03:00
|
|
|
}
|
2022-06-17 11:05:17 +01:00
|
|
|
EnumTypeTraversalImpl! {
|
|
|
|
impl<'tcx, T> TypeVisitable<'tcx> for Option<T> {
|
|
|
|
(Some)(a),
|
|
|
|
(None),
|
|
|
|
} where T: TypeVisitable<'tcx>
|
|
|
|
}
|
2015-09-06 21:51:58 +03:00
|
|
|
|
2022-06-17 11:05:17 +01:00
|
|
|
EnumTypeTraversalImpl! {
|
2019-05-31 10:23:22 +02:00
|
|
|
impl<'tcx, T, E> TypeFoldable<'tcx> for Result<T, E> {
|
|
|
|
(Ok)(a),
|
|
|
|
(Err)(a),
|
|
|
|
} where T: TypeFoldable<'tcx>, E: TypeFoldable<'tcx>,
|
|
|
|
}
|
2022-06-17 11:05:17 +01:00
|
|
|
EnumTypeTraversalImpl! {
|
|
|
|
impl<'tcx, T, E> TypeVisitable<'tcx> for Result<T, E> {
|
|
|
|
(Ok)(a),
|
|
|
|
(Err)(a),
|
|
|
|
} where T: TypeVisitable<'tcx>, E: TypeVisitable<'tcx>,
|
|
|
|
}
|
2019-05-31 10:23:22 +02:00
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeFoldable<'tcx>> ir::TypeFoldable<'tcx> for Rc<T> {
|
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
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(
|
2021-11-29 12:55:00 +00:00
|
|
|
mut self,
|
2021-12-01 00:55:57 +00:00
|
|
|
folder: &mut F,
|
|
|
|
) -> Result<Self, F::Error> {
|
2021-11-29 12:55:00 +00:00
|
|
|
// We merely want to replace the contained `T`, if at all possible,
|
|
|
|
// so that we don't needlessly allocate a new `Rc` or indeed clone
|
|
|
|
// the contained type.
|
|
|
|
unsafe {
|
|
|
|
// First step is to ensure that we have a unique reference to
|
|
|
|
// the contained type, which `Rc::make_mut` will accomplish (by
|
|
|
|
// allocating a new `Rc` and cloning the `T` only if required).
|
|
|
|
// This is done *before* casting to `Rc<ManuallyDrop<T>>` so that
|
|
|
|
// panicking during `make_mut` does not leak the `T`.
|
|
|
|
Rc::make_mut(&mut self);
|
|
|
|
|
|
|
|
// Casting to `Rc<ManuallyDrop<T>>` is safe because `ManuallyDrop`
|
|
|
|
// is `repr(transparent)`.
|
|
|
|
let ptr = Rc::into_raw(self).cast::<ManuallyDrop<T>>();
|
|
|
|
let mut unique = Rc::from_raw(ptr);
|
|
|
|
|
|
|
|
// Call to `Rc::make_mut` above guarantees that `unique` is the
|
|
|
|
// sole reference to the contained value, so we can avoid doing
|
|
|
|
// a checked `get_mut` here.
|
|
|
|
let slot = Rc::get_mut_unchecked(&mut unique);
|
|
|
|
|
|
|
|
// Semantically move the contained type out from `unique`, fold
|
2022-11-16 20:34:16 +00:00
|
|
|
// it, then move the folded value back into `unique`. Should
|
2021-11-29 12:55:00 +00:00
|
|
|
// folding fail, `ManuallyDrop` ensures that the "moved-out"
|
|
|
|
// value is not re-dropped.
|
|
|
|
let owned = ManuallyDrop::take(slot);
|
|
|
|
let folded = owned.try_fold_with(folder)?;
|
|
|
|
*slot = ManuallyDrop::new(folded);
|
|
|
|
|
|
|
|
// Cast back to `Rc<T>`.
|
|
|
|
Ok(Rc::from_raw(Rc::into_raw(unique).cast()))
|
|
|
|
}
|
2015-09-06 21:51:58 +03:00
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2015-11-18 09:38:57 +00:00
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeVisitable<'tcx>> ir::TypeVisitable<'tcx> for Rc<T> {
|
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
|
|
|
fn visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
2015-11-18 09:38:57 +00:00
|
|
|
(**self).visit_with(visitor)
|
|
|
|
}
|
2015-09-06 21:51:58 +03:00
|
|
|
}
|
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeFoldable<'tcx>> ir::TypeFoldable<'tcx> for Arc<T> {
|
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
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(
|
2021-11-29 12:55:00 +00:00
|
|
|
mut self,
|
2021-12-01 00:55:57 +00:00
|
|
|
folder: &mut F,
|
|
|
|
) -> Result<Self, F::Error> {
|
2021-11-29 12:55:00 +00:00
|
|
|
// We merely want to replace the contained `T`, if at all possible,
|
|
|
|
// so that we don't needlessly allocate a new `Arc` or indeed clone
|
|
|
|
// the contained type.
|
|
|
|
unsafe {
|
|
|
|
// First step is to ensure that we have a unique reference to
|
|
|
|
// the contained type, which `Arc::make_mut` will accomplish (by
|
|
|
|
// allocating a new `Arc` and cloning the `T` only if required).
|
|
|
|
// This is done *before* casting to `Arc<ManuallyDrop<T>>` so that
|
|
|
|
// panicking during `make_mut` does not leak the `T`.
|
|
|
|
Arc::make_mut(&mut self);
|
|
|
|
|
|
|
|
// Casting to `Arc<ManuallyDrop<T>>` is safe because `ManuallyDrop`
|
|
|
|
// is `repr(transparent)`.
|
|
|
|
let ptr = Arc::into_raw(self).cast::<ManuallyDrop<T>>();
|
|
|
|
let mut unique = Arc::from_raw(ptr);
|
|
|
|
|
|
|
|
// Call to `Arc::make_mut` above guarantees that `unique` is the
|
|
|
|
// sole reference to the contained value, so we can avoid doing
|
|
|
|
// a checked `get_mut` here.
|
|
|
|
let slot = Arc::get_mut_unchecked(&mut unique);
|
|
|
|
|
|
|
|
// Semantically move the contained type out from `unique`, fold
|
2022-11-16 20:34:16 +00:00
|
|
|
// it, then move the folded value back into `unique`. Should
|
2021-11-29 12:55:00 +00:00
|
|
|
// folding fail, `ManuallyDrop` ensures that the "moved-out"
|
|
|
|
// value is not re-dropped.
|
|
|
|
let owned = ManuallyDrop::take(slot);
|
|
|
|
let folded = owned.try_fold_with(folder)?;
|
|
|
|
*slot = ManuallyDrop::new(folded);
|
|
|
|
|
|
|
|
// Cast back to `Arc<T>`.
|
|
|
|
Ok(Arc::from_raw(Arc::into_raw(unique).cast()))
|
|
|
|
}
|
2019-06-18 19:15:31 -04:00
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2019-06-18 19:15:31 -04:00
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeVisitable<'tcx>> ir::TypeVisitable<'tcx> for Arc<T> {
|
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
|
|
|
fn visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
2019-06-18 19:15:31 -04:00
|
|
|
(**self).visit_with(visitor)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeFoldable<'tcx>> ir::TypeFoldable<'tcx> for Box<T> {
|
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
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error> {
|
2021-12-01 00:55:57 +00:00
|
|
|
self.try_map_id(|value| value.try_fold_with(folder))
|
2015-09-06 21:51:58 +03:00
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2015-11-18 09:38:57 +00:00
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeVisitable<'tcx>> ir::TypeVisitable<'tcx> for Box<T> {
|
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
|
|
|
fn visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
2015-11-18 09:38:57 +00:00
|
|
|
(**self).visit_with(visitor)
|
|
|
|
}
|
2015-09-06 21:51:58 +03:00
|
|
|
}
|
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeFoldable<'tcx>> ir::TypeFoldable<'tcx> for Vec<T> {
|
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
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error> {
|
2021-12-01 00:55:57 +00:00
|
|
|
self.try_map_id(|t| t.try_fold_with(folder))
|
2015-09-06 21:51:58 +03:00
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2015-11-18 09:38:57 +00:00
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeVisitable<'tcx>> ir::TypeVisitable<'tcx> for Vec<T> {
|
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
|
|
|
fn visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
2020-10-21 14:22:44 +02:00
|
|
|
self.iter().try_for_each(|t| t.visit_with(visitor))
|
2015-11-18 09:38:57 +00:00
|
|
|
}
|
2015-09-06 21:51:58 +03:00
|
|
|
}
|
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeVisitable<'tcx>> ir::TypeVisitable<'tcx> for &[T] {
|
2022-08-28 01:22:51 +00:00
|
|
|
fn visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
|
|
|
self.iter().try_for_each(|t| t.visit_with(visitor))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeFoldable<'tcx>> ir::TypeFoldable<'tcx> for Box<[T]> {
|
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
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error> {
|
2021-12-01 00:55:57 +00:00
|
|
|
self.try_map_id(|t| t.try_fold_with(folder))
|
2018-09-24 12:13:23 +10:00
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2018-09-24 12:13:23 +10:00
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeVisitable<'tcx>> ir::TypeVisitable<'tcx> for Box<[T]> {
|
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
|
|
|
fn visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
2020-10-21 14:22:44 +02:00
|
|
|
self.iter().try_for_each(|t| t.visit_with(visitor))
|
2018-09-24 12:13:23 +10:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeFoldable<'tcx>> ir::TypeFoldable<'tcx> for ty::Binder<'tcx, T> {
|
2021-12-01 15:11:24 +00:00
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error> {
|
2021-12-01 00:55:57 +00:00
|
|
|
folder.try_fold_binder(self)
|
2016-01-06 02:01:28 +00:00
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2016-01-06 02:01:28 +00:00
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeVisitable<'tcx>> ir::TypeVisitable<'tcx> for ty::Binder<'tcx, T> {
|
2020-11-05 17:30:39 +01:00
|
|
|
fn visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
2016-01-08 23:34:05 +00:00
|
|
|
visitor.visit_binder(self)
|
2015-11-18 09:38:57 +00:00
|
|
|
}
|
2015-09-06 21:51:58 +03: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
|
|
|
impl<'tcx, T: TypeFoldable<'tcx>> TypeSuperFoldable<'tcx> for ty::Binder<'tcx, T> {
|
2021-12-01 15:11:24 +00:00
|
|
|
fn try_super_fold_with<F: FallibleTypeFolder<'tcx>>(
|
2021-12-01 00:55:57 +00:00
|
|
|
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))
|
2015-11-18 09:38:57 +00:00
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2015-11-18 09:38:57 +00:00
|
|
|
|
2022-06-17 12:09:23 +01:00
|
|
|
impl<'tcx, T: TypeVisitable<'tcx>> TypeSuperVisitable<'tcx> for ty::Binder<'tcx, T> {
|
2020-11-05 17:30:39 +01:00
|
|
|
fn super_visit_with<V: TypeVisitor<'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-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeFoldable<'tcx> for &'tcx ty::List<ty::PolyExistentialPredicate<'tcx>> {
|
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
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error> {
|
|
|
|
ty::util::fold_list(self, folder, |tcx, v| tcx.intern_poly_existential_predicates(v))
|
|
|
|
}
|
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-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeFoldable<'tcx> for &'tcx ty::List<ty::Const<'tcx>> {
|
2022-07-27 07:27:52 +00:00
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error> {
|
|
|
|
ty::util::fold_list(self, folder, |tcx, v| tcx.mk_const_list(v.iter()))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeFoldable<'tcx> for &'tcx ty::List<ProjectionKind> {
|
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
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error> {
|
2020-10-24 09:27:15 +02:00
|
|
|
ty::util::fold_list(self, folder, |tcx, v| tcx.intern_projs(v))
|
2018-10-26 13:32:45 +02:00
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2018-10-26 13:32:45 +02:00
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeFoldable<'tcx> for Ty<'tcx> {
|
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
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error> {
|
|
|
|
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-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeVisitable<'tcx> for Ty<'tcx> {
|
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
|
|
|
fn visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
|
|
|
visitor.visit_ty(*self)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'tcx> TypeSuperFoldable<'tcx> for Ty<'tcx> {
|
2021-12-01 15:11:24 +00:00
|
|
|
fn try_super_fold_with<F: FallibleTypeFolder<'tcx>>(
|
2021-12-01 00:55:57 +00:00
|
|
|
self,
|
|
|
|
folder: &mut F,
|
|
|
|
) -> Result<Self, F::Error> {
|
2020-10-24 09:27:15 +02:00
|
|
|
let kind = match *self.kind() {
|
2021-12-01 00:55:57 +00:00
|
|
|
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)?),
|
2022-04-13 16:11:28 -07:00
|
|
|
ty::Dynamic(trait_ty, region, representation) => ty::Dynamic(
|
|
|
|
trait_ty.try_fold_with(folder)?,
|
|
|
|
region.try_fold_with(folder)?,
|
|
|
|
representation,
|
|
|
|
),
|
2021-12-01 00:55:57 +00:00
|
|
|
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)
|
2015-06-13 13:15:03 -07:00
|
|
|
}
|
2018-08-22 01:35:02 +01:00
|
|
|
ty::Generator(did, substs, movability) => {
|
2021-12-01 00:55:57 +00:00
|
|
|
ty::Generator(did, substs.try_fold_with(folder)?, movability)
|
2017-07-05 14:57:26 -07:00
|
|
|
}
|
2021-12-01 00:55:57 +00: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)?)
|
|
|
|
}
|
2021-12-01 00:55:57 +00:00
|
|
|
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(_)
|
2020-05-05 23:02:09 -05:00
|
|
|
| ty::Error(_)
|
2018-10-22 20:37:56 +02:00
|
|
|
| ty::Infer(_)
|
|
|
|
| ty::Param(..)
|
|
|
|
| ty::Bound(..)
|
2018-11-02 18:48:24 +01:00
|
|
|
| ty::Placeholder(..)
|
2018-10-22 20:37:56 +02:00
|
|
|
| ty::Never
|
2021-05-19 13:34:54 +02:00
|
|
|
| ty::Foreign(..) => return Ok(self),
|
2015-11-18 09:38:57 +00:00
|
|
|
};
|
2016-11-24 21:10:08 +11:00
|
|
|
|
2021-05-19 13:34:54 +02:00
|
|
|
Ok(if *self.kind() == kind { self } else { folder.tcx().mk_ty(kind) })
|
2015-11-18 09:38:57 +00:00
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2015-11-18 09:38:57 +00:00
|
|
|
|
2022-06-17 12:09:23 +01:00
|
|
|
impl<'tcx> TypeSuperVisitable<'tcx> for Ty<'tcx> {
|
2020-11-05 17:30:39 +01:00
|
|
|
fn super_visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
2020-08-03 00:49:11 +02:00
|
|
|
match self.kind() {
|
2018-08-22 01:35:02 +01:00
|
|
|
ty::RawPtr(ref tm) => tm.visit_with(visitor),
|
2020-10-21 14:22:44 +02:00
|
|
|
ty::Array(typ, sz) => {
|
|
|
|
typ.visit_with(visitor)?;
|
|
|
|
sz.visit_with(visitor)
|
|
|
|
}
|
2018-08-22 01:35:02 +01:00
|
|
|
ty::Slice(typ) => typ.visit_with(visitor),
|
|
|
|
ty::Adt(_, substs) => substs.visit_with(visitor),
|
2022-04-13 16:11:28 -07:00
|
|
|
ty::Dynamic(ref trait_ty, ref reg, _) => {
|
2020-10-21 14:22:44 +02:00
|
|
|
trait_ty.visit_with(visitor)?;
|
|
|
|
reg.visit_with(visitor)
|
2019-12-22 17:42:04 -05:00
|
|
|
}
|
2018-08-22 01:35:02 +01:00
|
|
|
ty::Tuple(ts) => ts.visit_with(visitor),
|
|
|
|
ty::FnDef(_, substs) => substs.visit_with(visitor),
|
|
|
|
ty::FnPtr(ref f) => f.visit_with(visitor),
|
2020-10-21 14:22:44 +02:00
|
|
|
ty::Ref(r, ty, _) => {
|
|
|
|
r.visit_with(visitor)?;
|
|
|
|
ty.visit_with(visitor)
|
|
|
|
}
|
2018-08-22 01:35:02 +01:00
|
|
|
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),
|
2018-08-22 01:35:02 +01:00
|
|
|
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(_)
|
2020-05-05 23:02:09 -05:00
|
|
|
| ty::Error(_)
|
2018-10-22 20:37:56 +02:00
|
|
|
| ty::Infer(_)
|
|
|
|
| ty::Bound(..)
|
2018-11-02 18:48:24 +01:00
|
|
|
| ty::Placeholder(..)
|
2018-10-22 20:37:56 +02:00
|
|
|
| ty::Param(..)
|
|
|
|
| ty::Never
|
2023-01-17 23:17:13 -08:00
|
|
|
| ty::Foreign(..) => ControlFlow::Continue(()),
|
2015-11-18 09:38:57 +00: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-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeFoldable<'tcx> for ty::Region<'tcx> {
|
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
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error> {
|
|
|
|
folder.try_fold_region(self)
|
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2015-09-06 21:51:58 +03:00
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeVisitable<'tcx> for ty::Region<'tcx> {
|
2020-11-05 17:30:39 +01:00
|
|
|
fn visit_with<V: TypeVisitor<'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
|
|
|
}
|
2016-01-06 02:01:28 +00:00
|
|
|
}
|
2015-11-18 09:38:57 +00: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
|
|
|
impl<'tcx> TypeSuperFoldable<'tcx> for ty::Region<'tcx> {
|
2021-12-01 15:11:24 +00:00
|
|
|
fn try_super_fold_with<F: FallibleTypeFolder<'tcx>>(
|
2021-12-01 00:55:57 +00:00
|
|
|
self,
|
|
|
|
_folder: &mut F,
|
|
|
|
) -> Result<Self, F::Error> {
|
2021-05-19 13:34:54 +02:00
|
|
|
Ok(self)
|
2016-01-06 02:01:28 +00:00
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2016-01-06 02:01:28 +00:00
|
|
|
|
2022-06-17 12:09:23 +01:00
|
|
|
impl<'tcx> TypeSuperVisitable<'tcx> for ty::Region<'tcx> {
|
2020-11-05 17:30:39 +01:00
|
|
|
fn super_visit_with<V: TypeVisitor<'tcx>>(&self, _visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
2023-01-17 23:17:13 -08:00
|
|
|
ControlFlow::Continue(())
|
2015-11-18 09:38:57 +00:00
|
|
|
}
|
2015-09-06 21:51:58 +03:00
|
|
|
}
|
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeFoldable<'tcx> for ty::Predicate<'tcx> {
|
2021-12-01 15:11:24 +00:00
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error> {
|
2021-12-01 00:55:57 +00:00
|
|
|
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-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeVisitable<'tcx> for ty::Predicate<'tcx> {
|
2020-11-05 17:30:39 +01:00
|
|
|
fn visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
2020-06-10 09:30:39 +01:00
|
|
|
visitor.visit_predicate(*self)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
impl<'tcx> TypeSuperFoldable<'tcx> for ty::Predicate<'tcx> {
|
2021-12-01 15:11:24 +00:00
|
|
|
fn try_super_fold_with<F: FallibleTypeFolder<'tcx>>(
|
2021-12-01 00:55:57 +00:00
|
|
|
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.tcx().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
|
|
|
|
2022-06-17 12:09:23 +01:00
|
|
|
impl<'tcx> TypeSuperVisitable<'tcx> for ty::Predicate<'tcx> {
|
2020-11-05 17:30:39 +01:00
|
|
|
fn super_visit_with<V: TypeVisitor<'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-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeFoldable<'tcx> for &'tcx ty::List<ty::Predicate<'tcx>> {
|
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
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error> {
|
|
|
|
ty::util::fold_list(self, folder, |tcx, v| tcx.intern_predicates(v))
|
|
|
|
}
|
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-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeFoldable<'tcx>, I: Idx> ir::TypeFoldable<'tcx> for IndexVec<I, T> {
|
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
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error> {
|
2021-12-01 00:55:57 +00:00
|
|
|
self.try_map_id(|x| x.try_fold_with(folder))
|
2017-02-08 22:19:22 +13:00
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2017-02-08 22:19:22 +13:00
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx, T: TypeVisitable<'tcx>, I: Idx> ir::TypeVisitable<'tcx> for IndexVec<I, T> {
|
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
|
|
|
fn visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
2020-10-21 14:22:44 +02:00
|
|
|
self.iter().try_for_each(|t| t.visit_with(visitor))
|
2017-02-08 22:19:22 +13:00
|
|
|
}
|
|
|
|
}
|
2017-07-08 23:24:00 +02:00
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeFoldable<'tcx> for ty::Const<'tcx> {
|
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
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(self, folder: &mut F) -> Result<Self, F::Error> {
|
|
|
|
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-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeVisitable<'tcx> for ty::Const<'tcx> {
|
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
|
|
|
fn visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
|
|
|
visitor.visit_const(*self)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'tcx> TypeSuperFoldable<'tcx> for ty::Const<'tcx> {
|
2021-12-01 15:11:24 +00:00
|
|
|
fn try_super_fold_with<F: FallibleTypeFolder<'tcx>>(
|
2021-12-01 00:55:57 +00:00
|
|
|
self,
|
|
|
|
folder: &mut F,
|
|
|
|
) -> Result<Self, F::Error> {
|
2022-02-02 14:24:45 +11:00
|
|
|
let ty = self.ty().try_fold_with(folder)?;
|
2022-06-10 11:18:06 +10:00
|
|
|
let kind = self.kind().try_fold_with(folder)?;
|
|
|
|
if ty != self.ty() || kind != self.kind() {
|
2022-11-04 20:33:32 +00:00
|
|
|
Ok(folder.tcx().mk_const(kind, ty))
|
2020-05-31 17:16:44 +02:00
|
|
|
} else {
|
2021-05-19 13:34:54 +02:00
|
|
|
Ok(self)
|
2020-05-31 17:16:44 +02:00
|
|
|
}
|
2018-12-11 19:56:59 +01:00
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2018-12-11 19:56:59 +01:00
|
|
|
|
2022-06-17 12:09:23 +01:00
|
|
|
impl<'tcx> TypeSuperVisitable<'tcx> for ty::Const<'tcx> {
|
2020-11-05 17:30:39 +01:00
|
|
|
fn super_visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
2022-02-02 14:24:45 +11:00
|
|
|
self.ty().visit_with(visitor)?;
|
2022-06-10 11:18:06 +10:00
|
|
|
self.kind().visit_with(visitor)
|
2017-08-04 11:25:13 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeFoldable<'tcx> for InferConst<'tcx> {
|
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
|
|
|
fn try_fold_with<F: FallibleTypeFolder<'tcx>>(self, _folder: &mut F) -> Result<Self, F::Error> {
|
2021-05-19 13:34:54 +02:00
|
|
|
Ok(self)
|
2019-05-06 14:05:26 +01:00
|
|
|
}
|
2022-06-17 12:09:23 +01:00
|
|
|
}
|
2019-05-06 14:05:26 +01:00
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeVisitable<'tcx> for InferConst<'tcx> {
|
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
|
|
|
fn visit_with<V: TypeVisitor<'tcx>>(&self, _visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
2023-01-17 23:17:13 -08:00
|
|
|
ControlFlow::Continue(())
|
2019-05-06 14:05:26 +01:00
|
|
|
}
|
|
|
|
}
|
2022-01-12 23:29:10 +00:00
|
|
|
|
2022-09-22 12:34:23 +02:00
|
|
|
impl<'tcx> TypeSuperVisitable<'tcx> for ty::UnevaluatedConst<'tcx> {
|
2022-01-12 23:29:10 +00:00
|
|
|
fn super_visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
|
|
|
self.substs.visit_with(visitor)
|
|
|
|
}
|
|
|
|
}
|
2023-01-22 17:06:28 -05:00
|
|
|
|
2023-02-09 14:02:47 +00:00
|
|
|
impl<'tcx> ir::TypeVisitable<'tcx> for TyAndLayout<'tcx, Ty<'tcx>> {
|
2023-01-22 17:06:28 -05:00
|
|
|
fn visit_with<V: TypeVisitor<'tcx>>(&self, visitor: &mut V) -> ControlFlow<V::BreakTy> {
|
|
|
|
visitor.visit_ty(self.ty)
|
|
|
|
}
|
|
|
|
}
|