eventual goal: re-remove leak-check from compiler

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.

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:

fixing those bugs unlocks
removing re-added leak-check, which unlocks
Chalk integration, which unlocks
generic associated types, which unlocks
better abstraction abilities for Rust, which unlocks
better and safer APIs?

@vi

@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....

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:

rust/src/librustc/infer/region_constraints/leak_check.rs

Lines 7 to 30 in 33d3598

    
               /// Searches region constraints created since `snapshot` that 
        
               /// affect one of the placeholders in `placeholder_map`, returning 
        
               /// an error if any of the placeholders are related to another 
        
               /// placeholder or would have to escape into some parent universe 
        
               /// that cannot name them. 
        
               /// 
        
               /// This is a temporary backwards compatibility measure to try and 
        
               /// retain the older (arguably incorrect) behavior of the 
        
               /// compiler. 
        
               /// 
        
               /// NB. The use of snapshot here is mostly an efficiency thing -- 
        
               /// we could search *all* region constraints, but that'd be a 
        
               /// bigger set and the data structures are not setup for that. If 
        
               /// we wind up keeping some form of this check long term, it would 
        
               /// probably be better to remove the snapshot parameter and to 
        
               /// refactor the constraint set. 
        
               pub fn leak_check( 
        
                   &mut self, 
        
                   tcx: TyCtxt<'_, '_, 'tcx>, 
        
                   overly_polymorphic: bool, 
        
                   placeholder_map: &PlaceholderMap<'tcx>, 
        
                   _snapshot: &CombinedSnapshot<'_, 'tcx>, 
        
               ) -> RelateResult<'tcx, ()> { 
        
                   debug!("leak_check(placeholders={:?})", placeholder_map);

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.

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.

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:

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

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

Rollup merge of rust-lang#70950 - nikomatsakis:leak-check-nll-2, r=ma…

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.

@rustbot

Discussed in T-compiler backlog bonanza

@rustbot label: S-tracking-unimplemented

Auto merge of rust-lang#119820 - lcnr:leak-check-2, r=<try>

I don't think this tracking issue is useful. We are reworking the way region handling works which is tracked in https://github.com/rust-lang/rust-project-goals/blob/main/src/2026/assumptions_on_binders.md. I don't think this tracking issue is useful for this and think the project goal will do a significantly better job here

Navigation Menu

Repository navigation

eventual goal: re-remove leak-check from compiler #59490

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	/// Searches region constraints created since `snapshot` that
	/// affect one of the placeholders in `placeholder_map`, returning
	/// an error if any of the placeholders are related to another
	/// placeholder or would have to escape into some parent universe
	/// that cannot name them.
	///
	/// This is a temporary backwards compatibility measure to try and
	/// retain the older (arguably incorrect) behavior of the
	/// compiler.
	///
	/// NB. The use of snapshot here is mostly an efficiency thing --
	/// we could search all region constraints, but that'd be a
	/// bigger set and the data structures are not setup for that. If
	/// we wind up keeping some form of this check long term, it would
	/// probably be better to remove the snapshot parameter and to
	/// refactor the constraint set.
	pub fn leak_check(
	&mut self,
	tcx: TyCtxt<'_, '_, 'tcx>,
	overly_polymorphic: bool,
	placeholder_map: &PlaceholderMap<'tcx>,
	_snapshot: &CombinedSnapshot<'_, 'tcx>,
	) -> RelateResult<'tcx, ()> {
	debug!("leak_check(placeholders={:?})", placeholder_map);

eventual goal: re-remove leak-check from compiler #59490

Description

Activity

vi commented on Mar 29, 2019

mark-i-m commented on Mar 29, 2019

pnkfelix commented on Apr 3, 2019

pnkfelix commented on Apr 3, 2019

nikomatsakis commented on Mar 26, 2020

nikomatsakis commented on Mar 26, 2020

lcnr commented on Jul 15, 2022

pnkfelix commented on Aug 12, 2022

lcnr commented on Feb 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions