Skip to content

Commit f161953

Browse files
committed
ExprUseVisitor: remove leftover mentions of mem-categorization
In #124902, mem-categorization got merged into ExprUseVisitor itself. Adjust the comments that have become misleading or confusing following this change.
1 parent aab1293 commit f161953

File tree

2 files changed

+16
-57
lines changed

2 files changed

+16
-57
lines changed

Diff for: compiler/rustc_hir_typeck/src/expr_use_visitor.rs

+11-52
Original file line numberDiff line numberDiff line change
@@ -867,7 +867,7 @@ impl<'tcx, Cx: TypeInformationCtxt<'tcx>, D: Delegate<'tcx>> ExprUseVisitor<'tcx
867867
}
868868

869869
/// Walks the autoref `autoref` applied to the autoderef'd
870-
/// `expr`. `base_place` is the mem-categorized form of `expr`
870+
/// `expr`. `base_place` is `expr` represented as a place,
871871
/// after all relevant autoderefs have occurred.
872872
fn walk_autoref(
873873
&self,
@@ -1170,53 +1170,15 @@ impl<'tcx, Cx: TypeInformationCtxt<'tcx>, D: Delegate<'tcx>> ExprUseVisitor<'tcx
11701170
}
11711171
}
11721172

1173-
/// The job of the categorization methods is to analyze an expression to
1174-
/// determine what kind of memory is used in evaluating it (for example,
1175-
/// where dereferences occur and what kind of pointer is dereferenced;
1176-
/// whether the memory is mutable, etc.).
1173+
/// The job of the methods whose name starts with `cat_` is to analyze
1174+
/// expressions and construct the corresponding [`Place`]s. The `cat`
1175+
/// stands for "categorize", this is a leftover from long ago when
1176+
/// places were called "categorizations".
11771177
///
1178-
/// Categorization effectively transforms all of our expressions into
1179-
/// expressions of the following forms (the actual enum has many more
1180-
/// possibilities, naturally, but they are all variants of these base
1181-
/// forms):
1182-
/// ```ignore (not-rust)
1183-
/// E = rvalue // some computed rvalue
1184-
/// | x // address of a local variable or argument
1185-
/// | *E // deref of a ptr
1186-
/// | E.comp // access to an interior component
1187-
/// ```
1188-
/// Imagine a routine ToAddr(Expr) that evaluates an expression and returns an
1189-
/// address where the result is to be found. If Expr is a place, then this
1190-
/// is the address of the place. If `Expr` is an rvalue, this is the address of
1191-
/// some temporary spot in memory where the result is stored.
1192-
///
1193-
/// Now, `cat_expr()` classifies the expression `Expr` and the address `A = ToAddr(Expr)`
1194-
/// as follows:
1195-
///
1196-
/// - `cat`: what kind of expression was this? This is a subset of the
1197-
/// full expression forms which only includes those that we care about
1198-
/// for the purpose of the analysis.
1199-
/// - `mutbl`: mutability of the address `A`.
1200-
/// - `ty`: the type of data found at the address `A`.
1201-
///
1202-
/// The resulting categorization tree differs somewhat from the expressions
1203-
/// themselves. For example, auto-derefs are explicit. Also, an index `a[b]` is
1204-
/// decomposed into two operations: a dereference to reach the array data and
1205-
/// then an index to jump forward to the relevant item.
1206-
///
1207-
/// ## By-reference upvars
1208-
///
1209-
/// One part of the codegen which may be non-obvious is that we translate
1210-
/// closure upvars into the dereference of a borrowed pointer; this more closely
1211-
/// resembles the runtime codegen. So, for example, if we had:
1212-
///
1213-
/// let mut x = 3;
1214-
/// let y = 5;
1215-
/// let inc = || x += y;
1216-
///
1217-
/// Then when we categorize `x` (*within* the closure) we would yield a
1218-
/// result of `*x'`, effectively, where `x'` is a `Categorization::Upvar` reference
1219-
/// tied to `x`. The type of `x'` will be a borrowed pointer.
1178+
/// Note that a [`Place`] differs somewhat from the expression itself. For
1179+
/// example, auto-derefs are explicit. Also, an index `a[b]` is decomposed into
1180+
/// two operations: a dereference to reach the array data and then an index to
1181+
/// jump forward to the relevant item.
12201182
impl<'tcx, Cx: TypeInformationCtxt<'tcx>, D: Delegate<'tcx>> ExprUseVisitor<'tcx, Cx, D> {
12211183
fn resolve_type_vars_or_bug(
12221184
&self,
@@ -1239,10 +1201,7 @@ impl<'tcx, Cx: TypeInformationCtxt<'tcx>, D: Delegate<'tcx>> ExprUseVisitor<'tcx
12391201
None => {
12401202
// FIXME: We shouldn't be relying on the infcx being tainted.
12411203
self.cx.tainted_by_errors()?;
1242-
bug!(
1243-
"no type for node {} in mem_categorization",
1244-
self.cx.tcx().hir_id_to_string(id)
1245-
);
1204+
bug!("no type for node {} in ExprUseVisitor", self.cx.tcx().hir_id_to_string(id));
12461205
}
12471206
}
12481207
}
@@ -1517,7 +1476,7 @@ impl<'tcx, Cx: TypeInformationCtxt<'tcx>, D: Delegate<'tcx>> ExprUseVisitor<'tcx
15171476
}
15181477
}
15191478

1520-
def => span_bug!(span, "unexpected definition in memory categorization: {:?}", def),
1479+
def => span_bug!(span, "unexpected definition in ExprUseVisitor: {:?}", def),
15211480
}
15221481
}
15231482

Diff for: compiler/rustc_hir_typeck/src/upvar.rs

+5-5
Original file line numberDiff line numberDiff line change
@@ -18,12 +18,12 @@
1818
//! from there).
1919
//!
2020
//! The fact that we are inferring borrow kinds as we go results in a
21-
//! semi-hacky interaction with mem-categorization. In particular,
22-
//! mem-categorization will query the current borrow kind as it
23-
//! categorizes, and we'll return the *current* value, but this may get
21+
//! semi-hacky interaction with the way `ExprUseVisitor` is computing
22+
//! `Place`s. In particular, it will query the current borrow kind as it
23+
//! goes, and we'll return the *current* value, but this may get
2424
//! adjusted later. Therefore, in this module, we generally ignore the
25-
//! borrow kind (and derived mutabilities) that are returned from
26-
//! mem-categorization, since they may be inaccurate. (Another option
25+
//! borrow kind (and derived mutabilities) that `ExprUseVisitor` returns
26+
//! within `Place`s, since they may be inaccurate. (Another option
2727
//! would be to use a unification scheme, where instead of returning a
2828
//! concrete borrow kind like `ty::ImmBorrow`, we return a
2929
//! `ty::InferBorrow(upvar_id)` or something like that, but this would

0 commit comments

Comments
 (0)