Introduce TypeVisitor::BreakTy

[LeSeulArtichaut]

Implements MCP rust-lang/compiler-team#383.
r? @ghost
cc @lcnr@oli-obk

Blocked on FCP in rust-lang/compiler-team#383.

[scottmcm]

❤️

[LeSeulArtichaut]

Yeah, I find the code so much cleaner this way 😄

[oli-obk]

I don't see the advantage of using a type other than () for the break in this case.

[LeSeulArtichaut]

(This was #78182 (comment))

[oli-obk]

Oh right, I remember that comment. @lcnr can you elaborate on the motivation? We should encode it in documentation/comments

[lcnr]

Using a ZST we explicitly document the reasons we stop visiting and the reason we check if we terminated early.

While it isn't too relevant, it makes it easier to prevent bugs like stopping early because of a different reason and forgetting to update a call site. I also feel like using a ZST here has a very low cost and removes some questions on why we are using is_break and under which conditions we want to stop visiting.

Don't really care too much about this though

[oli-obk]

I have nothing to argue against that 😆

If we can manage to remove is_break in that case (when all visitors have been migrated), then that would enforce this by there not being a way around it.

[oli-obk]

Oh... now that I finished reading the PR, I think we should also stop having () as a default for BreakTy and require the user to specify one (or use ! as the default?)

[lcnr]

using ! as a default would be interesting 🤔 can't be misused and makes people notice the possibility

[LeSeulArtichaut]

65cdc21 🙂

[LeSeulArtichaut]

r? @oli-obk

[lcnr]

✨

[lcnr]

this is such a huge improvement to the implementation which still used bools ❤️ thank you for implementing all of this

[lcnr]

It looks to me like there are actually 2 visitors merged into 1 here.

The first one finds all opaque types and the second one then searches for inherited parent lifetimes, might make sense to try and split this. Not sure if you want to do this in one PR

[lcnr]

(depends on https://github.com/rust-lang/rust/pull/78779/files#r519026794)

[lcnr]

Can ty.unwrap() fail here? I would expect this to not be the case. Might be missing something though.

Maybe if we have a PredicateAtom::RegionOutlives 🤔

[LeSeulArtichaut]

IIUC it can: https://github.com/rust-lang/rust/blob/149f593bf6d204ea226461c18a95f558a6ad250b/compiler/rustc_typeck/src/check/check.rs#L462-L473

[lcnr]

yeah, but this only ends up returning None if we aren't inside of a type, as we would otherwise return Some(ty) there

edit: this may happen if the predicate is an outlives predicate though I don't know if they are possible for opaque types, don't have the capacity to look into this myself atm

[lcnr]

I personally would like to push a bit more to using ZST here and pretty much never use (). So I wouldn't add a associated type default here.

afaict @oli-obk has a different opinion so I am also fine with merging this as is.

[LeSeulArtichaut]

We could change things in follow-up PRs. I made every change in a separate commit so I can easily drop some.

[oli-obk]

Maybe create a self.check_flags method that handles this intersects call and the if-condition?

[oli-obk]

r=me,lcnr with the dead function removed

[LeSeulArtichaut]

Done.
Note: rust-lang/compiler-team#383 still has two more hours in FCP to be accepted, but I haven't seen any objections anywhere so by the time this lands the MCP should be accepted.

[oli-obk]

@bors r+

yea, I think we can safely send it to bors, too

[bors]

📌 Commit f6e6a15 has been approved by oli-obk

[LeSeulArtichaut]

Should this be rollup=never as a medium-sized refractor? (I'm still trying to understand what deserves rollup=never besides perf-sensitive changes)

[oli-obk]

for non-perf non prioritized things that probably conflict with a bunch of things we have

@bors rollup=iffy

[bors]

⌛ Testing commit f6e6a15 with merge aacb816092fb150a8459de3135f62d6199fedf62...

[bors]

💥 Test timed out

[oli-obk]

@bors retry

[bors]

⌛ Testing commit f6e6a15 with merge e0ef0fc...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing e0ef0fc to master...