afa8acce25
NLL: Limit two-phase borrows to autoref-introduced borrows This imposes a restriction on two-phase borrows so that it only applies to autoref-introduced borrows. The goal is to ensure that our initial deployment of two-phase borrows is very conservative. We want it to still cover the `v.push(v.len());` example, but we do not want it to cover cases like `let imm = &v; let mu = &mut v; mu.push(imm.len());` (Why do we want it to be conservative? Because when you are not conservative, then the results you get, at least with the current analysis, are tightly coupled to details of the MIR construction that we would rather remain invisible to the end user.) Fix #46747 I decided, for this PR, to add a debug-flag `-Z two-phase-beyond-autoref`, to re-enable the more general approach. But my intention here is *not* that we would eventually turn on that debugflag by default; the main reason I added it was that I thought it was useful for writing tests to be able to write source that looks like desugared MIR. |
||
|---|---|---|
| .. | ||
| check | ||
| coherence | ||
| outlives | ||
| variance | ||
| astconv.rs | ||
| Cargo.toml | ||
| check_unused.rs | ||
| collect.rs | ||
| constrained_type_params.rs | ||
| diagnostics.rs | ||
| impl_wf_check.rs | ||
| lib.rs | ||
| namespace.rs | ||
| README.md | ||
| structured_errors.rs | ||
NB: This crate is part of the Rust compiler. For an overview of the
compiler as a whole, see
the README.md file found in librustc.
The rustc_typeck crate contains the source for "type collection" and
"type checking", as well as a few other bits of related functionality.
(It draws heavily on the type inferencing and
trait solving code found in librustc.)
Type collection
Type "collection" is the process of converting the types found in the
HIR (hir::Ty), which represent the syntactic things that the user
wrote, into the internal representation used by the compiler
(Ty<'tcx>) -- we also do similar conversions for where-clauses and
other bits of the function signature.
To try and get a sense for the difference, consider this function:
struct Foo { }
fn foo(x: Foo, y: self::Foo) { .. }
// ^^^ ^^^^^^^^^
Those two parameters x and y each have the same type: but they
will have distinct hir::Ty nodes. Those nodes will have different
spans, and of course they encode the path somewhat differently. But
once they are "collected" into Ty<'tcx> nodes, they will be
represented by the exact same internal type.
Collection is defined as a bundle of queries (e.g., type_of) for
computing information about the various functions, traits, and other
items in the crate being compiled. Note that each of these queries is
concerned with interprocedural things -- for example, for a function
definition, collection will figure out the type and signature of the
function, but it will not visit the body of the function in any way,
nor examine type annotations on local variables (that's the job of
type checking).
For more details, see the collect module.
Type checking
TODO