Handle ReVar in note_and_explain_region

[nnethercote]

PR #124918 made this path abort. The added test, from fuzzing, identified that it is reachable.

r? @lcnr

[nnethercote]

Prior to #124918 there was this comment:

        // We shouldn't really be having unification failures with ReVar
        // and ReBound though.
        //
        // FIXME(@lcnr): Figure out whether this is reachable and if so, why.
        ty::ReVar(_) | ty::ReBound(..) | ty::ReErased => (format!("lifetime `{region}`"), alt_span),

We now know how ReVar can occur here. I don't know if this is considered reasonable or not.

I also am not sure if I chose a good spot for the new test.

@bors rollup

[compiler-errors]

Huh. This seems a bit sus to me tbh

I don't know if this is considered reasonable or not.

I would like to understand more clearly why we're encountering ReVar in the signature of the function. It's not clearly correct to me, and it's possibly better fixed by modifying some other code.

Please also move "fix #124973" out of the title and into the body of the PR so it actually cross-links and closes the issue correctly, and give the PR a better title.

[nnethercote]

I would like to understand more clearly why we're encountering ReVar in the signature of the function. It's not clearly correct to me, and it's possibly better fixed by modifying some other code.

I am unlikely to be the person to make changes elsewhere :) Maybe @lcnr has an opinion on this?

[compiler-errors]

Well, If you're too busy to look into what the root cause of this ICE is, I'd prefer if we close this PR and leave the underlying issue open instead of just changing it back to silently accept.

I don't think that it's urgent enough that we should land this without investigation, especially since this is of the Error -> ICE category and doesn't affect code that I expect "regular" usages of rustc to hit often.

[compiler-errors]

Actually in the process of writing that comment out I think I figured out what the issue is. Give me a few mins; I'll put something up to fix this with a better diagnostic.

[nnethercote]

I'm not too busy, I just don't know much about region analysis :)

[compiler-errors]

So the tl;dr is:

rust/compiler/rustc_borrowck/src/universal_regions.rs

Lines 517 to 520 in 9105c57

	let reg_vid = self
	.infcx
	.next_nll_region_var(FR, || RegionCtxt::Free(Symbol::intern("c-variadic")))
	.as_var();

We create an anonymous free region here for the VaListImpl<'_> that c-variadic is implicitly lowered to.

Async functions capture that var arg list (not exactly certain how they end up doing that, though), and so the lifetime ends up being captured by the async fn's future. That ends up erroring because the future ends up capturing a lifetime that it didn't expect, which should probably not happen, but regardless is a problem because we have no way of providing a useful error message even if we don't expect it to work.

Probably won't be able to put up a PR to fix this, at least not tonight since it's 23:30, and am becoming more sympathetic to land this PR with a FIXME, a better PR title, and a follow-up issue filed about how the diagnostic isn't useful at all, so we can link it w/ the c_variadic tracking issue at least. Do you want to do that?

[compiler-errors]

@rustbot author

see comment above for leaving a fixme and linking w/ a FIXME issue for bad diagnostics to the tracking issue

[compiler-errors]

@bors r+ rollup

[bors]

📌 Commit 5f4424b has been approved by compiler-errors

It is now in the queue for this repository.

[nnethercote]

I have updated the description, filed #125431 as a follow-up, and added a FIXME comment. Can you add the relevant labels/markings to the follow-up issue for the c_variadic tracking?