eventual goal: re-remove leak-check from compiler

[pnkfelix]

PR #58592 re-added the so-called leak check.

Re-adding the leak-check masked a number of bugs, where you need to use -Z no-leak-check to observe them again.

We plan to eventually re-remove the leak check. But before doing so, we need to double-check that all of the aforementioned masked bugs are either fixed, or at the very least revisited in terms of determining their priority in a leak-check-free world.

[vi]

What is a leak check? How it masks the bugs? What Github label do those leak-check-masked bugs carry?

Google search does not seem to show relevant things; asking on IRC lead to answerer suggesting to ask here.

Do I understand the chain correctly:

1. fixing those bugs unlocks
2. removing re-added leak-check, which unlocks
3. Chalk integration, which unlocks
4. generic associated types, which unlocks
5. better abstraction abilities for Rust, which unlocks
6. better and safer APIs?

[mark-i-m]

@vi perhaps @pnkfelix can correct me if i am mistaken. I think they are referring to Placeholder leaks, which was the old way of handling HRTB lifetimes. My guess is that there is some difference in how Universes (the new way) work that caused edge case bugs or something....

[pnkfelix]

I think they are referring to Placeholder leaks, which was the old way of handling HRTB lifetimes.

Yes, this matches my own understanding.

The check that was re-added in PR #58592 has a big comment above its core function, here:

https://github.com/rust-lang/rust/blob/33d3598e3b57c0fcfd36f34c346847bcc4edd3d2/src/librustc/infer/region_constraints/leak_check.rs#L7-L30

I think the rustc guide mark-i-m linked is the best place for a new-comer to start; but I also do not know if the strategy outlined for handling leaks corresponds to our ideal-but-not-yet-the-default solution, or if the ideal solution is not yet documented there.

---

I am not an expert here. PR #58592 says the main reason to re-remove the leak check is that the leak-check does not handle higher-ranked types correctly in all cases.

What I do not know is whether the remaining buggy cases motivating removal of the leak check are all instances of expressiveness bugs (programs that we want to accept but currently reject), or if some of them are soundness issues. I think it is just an expressiveness issue, but I am not sure of that.

[pnkfelix]

What is a leak check? How it masks the bugs? What Github label do those leak-check-masked bugs carry?

I say that the leak check is "masking bugs" because it is causing the rustc compiler to reject programs relatively early (due to them violating the leak check), but those same programs, if we do get rid of the leak check, end up hitting some bug downstream that causes an internal compiler error.

Currently all such bugs that I know of are things that arise from interactions with non-lexical lifetimes, perhaps in part due to the MIR typeck pass that is in charge of checking the correctness of higher-ranked types (and without the leak check, a larger class of potential higher-ranked types ends up being fed into the MIR typeck pass).

It is possible that there are other bugs that belong in this category that are not due to interaction with non-lexical lifetime. I am just not yet aware of any such cases; it is an unknown quantity.

We have not allocated a github-label dedicated solely to these masked bugs (and I do not think that we should allocate such a label). I think it will suffice for such bugs to mention this isue (#59490) so that they end up being linked from this page.

[nikomatsakis]

So #65232 made good progress towards this goal by adding universes to the 'empty regions and thus ensuring that we don't have any region R1 where forall<R2> { R2: R1 } is true. However, this work did not extend to the NLL checker. Therefore, I think the major remaining work items are as follows:

• [x] extend the NLL check to avoid a notion of a 'empty value
• [ ] resolve the confusing error messages that may result
• [ ] integrate empty into the canonicalizer (see FIXME)
• [ ] figure out how to resolve the wasm-bindgen regression

[nikomatsakis]

I'm looking some into that first point and will probably create a spin-out issue for it and put more details there.

[lcnr]

discussed in the t-types backlog bonanza

While the plan for how we want to remove the leak check has changed, we still intend to remove the current version, so we're keeping this open to track that for now.

The goal is to pretty much add a param_env aware leak check directly into trait solving and remove the current impl.

[pnkfelix]

Discussed in T-compiler backlog bonanza

@rustbot label: S-tracking-unimplemented