So, here's a fun thing I stumbled upon..
(I wasn't able to find any existing discussion, issues or PRs about this, I'd not be surprised if someone had found it already, so my bad if this isn't a new problem)
I was about to take a look into #59494 (the test case for that will trigger this if you want to follow along at home). I did the first thing I always do, get a backtrace, look at log output and try get a rough idea what is happening where the error/ICE is triggered. But, when I set
RUST_LOG=rustc::traits, the error changes - I can see the ICE with just
RUST_LOG=rustc::traits::select (IIRC), but not with more than that - I get a cycle error instead.
I guess I'll look into that, I find out it comes from the pretty printer, in particular this line. Alright, I guess somewhere in that function's call stack, something is doing something it shouldn't and calling
predicates_of with the same key.
Here's the diff that fixed it (when I was using
RUST_LOG=rustc::ty::subst,rustc::ty::context,rustc_typeck which is what I had when I figured this out, I'm sure there are more problematic
debug! statements in other modules, like
rustc::traits::*). The issue was that the pretty printer calling
predicates_of ended up calling code with debug logs that were printing the same type, causing a cycle. I have no idea what to do about this.
Any thoughts? As far as I can tell, there's no easy way for someone modifying
rustc_typeck (for example) to know not to print a type in a debug statement because that code is in the path of the pretty printer.
I filed an issue for this, #59985, so it isn't forgotten about.
We have a test which prints debug stuff, but I only think it's a hello word example
I think this would only happen for existential types, as that was the only type that called
predicates_of during printing (IIRC from when I looked last night).
I’m just not sure how to go about fixing it otherwise I’d have had a PR in.
Hmm. One way is to generalize the printer to be able to handle cyclic graph structures
But that’s a fair amount of effort
In the short(er) term we could try tracking whether we are currently already executing the pretty printing code and change what we print for existential types in that context