# Temporary drop order edition lint

Observations from [improved crater run results](https://github.com/rust-lang/rust/pull/129864#issuecomment-2376658407):

* Wording could be improved for clarity (not looking into this now)
* Spans are not a reliable or precise way to identify tail expressions; we see a lot of underlines and we don't know why
* Some suspicious types
* e.g., `proc_macro2::Ident` -- does that truly have a significant destructor?
* which one is it??
* [e.g. crater](https://crater-reports.s3.amazonaws.com/pr-129864/try%237014e13d5becc920d4bea3cd87942c8a13d359bf%2Brustflags=-Dtail_expr_drop_order/reg/impl-trait-for-tuples-0.2.2/log.txt)
* There could be a bug in the impl
* Lots of other seemingly spurious cases
* Two options
* allow-list a bunch of types
* examine and maybe tighten existing heuristics
* find what is reachable from the destructor

We should point out why a type has a significant dtor (like, the *leafmost* type for why an otherwise aggregate type has a drop).

dingxiangfei follow up ?:
* Print fully qualified types (maybe for foreign types? idk)

errs follow-up:
* Mark `std::io::Error` as having insignificant dtor
* Add a rustc_* flag to test insignificant
* Make sure that insignificant dtor considers `Copy`

the uniquified list of types:
https://gist.github.com/nikomatsakis/9979ecde375d4b2a5ff6e4e81bee453d

## Code review info

### span info to determine membership of MIR stmts to tail expr (13k failures)

https://github.com/rust-lang/rust/pull/129864/files?diff=unified&w=0#diff-4b60d94e8e00b00d4e4b20953bc808c9b5fe4477149c7655bd1719df78690f5aR131-R159

Those statements that has span falling into the `tail_expr_span` is considered as part of the tail expr evaluation. Now it is possible that the control flow is interleaved with other statements outside the tail expr span, e.g. macro expansion results, we need to coalesce those statements into an MIR code region that encompasses the entire tail expr evaluation.

The next critical step is to identify the exit boundary of the tail expr that eventually reaches the exit point. The current approach takes a set subtraction of the MIR code region and others that on paths to the exit `exit_tail_expr_blocks`, with those that are on a path from the entry block to any block in the code region `tail_expr_blocks`.

### use of the scope `HirId`
https://github.com/rust-lang/rust/pull/129864/files?diff=unified&w=0#diff-4b60d94e8e00b00d4e4b20953bc808c9b5fe4477149c7655bd1719df78690f5aR171-R185

### the old HIR-based approach (70k failures)
https://github.com/rust-lang/rust/blob/f2becdff0496003217e7fc6fbfcaf2640e162775/compiler/rustc_lint/src/tail_expr_drop_order.rs