reduce false positives of tail-expr-drop-order from consumed values

take 2

open up coroutines

tweak the wordings

the lint works up until 2021

We were missing one case, for ADTs, which was
causing `Result` to yield incorrect results.

only include field spans with significant types

deduplicate and eliminate field spans

switch to emit spans to impl Drops

Co-authored-by: Niko Matsakis <nikomat@amazon.com>

collect drops instead of taking liveness diff

apply some suggestions and add explantory notes

small fix on the cache

let the query recurse through coroutine

new suggestion format with extracted variable name

fine-tune the drop span and messages

bugfix on runtime borrows

tweak message wording

filter out ecosystem types earlier

apply suggestions

clippy

check lint level at session level

further restrict applicability of the lint

translate bid into nop for stable mir

detect cycle in type structure
This commit is contained in:
Ding Xiang Fei 2024-09-02 01:13:07 +08:00
parent 70e814bd9e
commit 297b618944
No known key found for this signature in database
GPG key ID: 3CD748647EEF6359
58 changed files with 2015 additions and 538 deletions

View file

@ -1448,6 +1448,28 @@ rustc_queries! {
cache_on_disk_if { false }
}
/// Returns a list of types which (a) have a potentially significant destructor
/// and (b) may be dropped as a result of dropping a value of some type `ty`
/// (in the given environment).
///
/// The idea of "significant" drop is somewhat informal and is used only for
/// diagnostics and edition migrations. The idea is that a significant drop may have
/// some visible side-effect on execution; freeing memory is NOT considered a side-effect.
/// The rules are as follows:
/// * Type with no explicit drop impl do not have significant drop.
/// * Types with a drop impl are assumed to have significant drop unless they have a `#[rustc_insignificant_dtor]` annotation.
///
/// Note that insignificant drop is a "shallow" property. A type like `Vec<LockGuard>` does not
/// have significant drop but the type `LockGuard` does, and so if `ty = Vec<LockGuard>`
/// then the return value would be `&[LockGuard]`.
/// *IMPORTANT*: *DO NOT* run this query before promoted MIR body is constructed,
/// because this query partially depends on that query.
/// Otherwise, there is a risk of query cycles.
query list_significant_drop_tys(ty: ty::ParamEnvAnd<'tcx, Ty<'tcx>>) -> &'tcx ty::List<Ty<'tcx>> {
desc { |tcx| "computing when `{}` has a significant destructor", ty.value }
cache_on_disk_if { false }
}
/// Computes the layout of a type. Note that this implicitly
/// executes in "reveal all" mode, and will normalize the input type.
query layout_of(