Liveness analysis for everybody

[tmiasko]

Perform liveness analysis for every body instead of limiting it to fns.

Fixes#77169.

[rust-highfive]

r? @oli-obk

(rust_highfive has picked a reviewer for you, use r? to override)

[lcnr]

LGTM!

I don't have too much experience with this code though, so I won't r+ this myself yet

[oli-obk]

@bors try @rust-timer queue

I don't care whether this has a perf impact, but I'd like to know before merging so we make a concious decision about it

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit e39c078321402714fafe8907a275515637bcfb9d with merge 775f8455dd97e8fb2f22eeb9a943bece2c4a64f4...

[oli-obk]

Not sure if the parent relation in the DefId space is set up like this, but can you try whether

ifletSome(parent) = self.tcx.parent(def_id){ifself.tcx.has_attr(parent, sym::automatically_derived){return;}}

also works? If so, please use that

[tmiasko]

Yep, that works as well.

Part of the motivation for the current form of the check was to avoid using the automatically_derived attribute if it were to occur in completely unexpected place, like a crate or a module. Should I change it anyway?

[oli-obk]

I think we should prevent such uses via other means, but you can also add an assert_eq!(self.tcx.def_kind(parent), DefKind::Impl) before the return to make sure.

[tmiasko]

We do not prevent such uses this right now, so I used this as a part of condition. I would like to be extra conservative about any additional uses of this attribute since I think it is stabilized unintentionally and its purpose has changed over time.

[oli-obk]

oh :/ that's not great. Yea let's go with a non-panicking version for now

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 775f8455dd97e8fb2f22eeb9a943bece2c4a64f4 (775f8455dd97e8fb2f22eeb9a943bece2c4a64f4)

[rust-timer]

Queued 775f8455dd97e8fb2f22eeb9a943bece2c4a64f4 with parent 535d27a, future comparison URL.

[rust-timer]

Finished benchmarking try commit (775f8455dd97e8fb2f22eeb9a943bece2c4a64f4): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[tmiasko]

The performance impact is limited, except for the many-assoc-items benchmark which contains mostly associated consts.

To a large degree we were paying the price of the computation already. The previous code was creating variables and lives nodes for all bodies, it just didn't always run the liveness analysis. Furthermore, when the liveness analysis didn't run, the live nodes and variables were included in the analysis of a parent if any.

[oli-obk]

@bors r+

I was expecting some sort of perf hit on assoc const heavy code, but this is a bugfix, so let's roll with it

[bors]

📌 Commit 924e8aa has been approved by oli-obk

[bors]

⌛ Testing commit 924e8aa with merge 939cc3e...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: oli-obk
Pushing 939cc3e to master...