Stream: t-compiler

Topic: pretty print type debug log cycle error


davidtwco (Apr 14 2019 at 23:35, on Zulip):

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.

davidtwco (Apr 15 2019 at 11:55, on Zulip):

I filed an issue for this, #59985, so it isn't forgotten about.

Zoxc (Apr 15 2019 at 11:57, on Zulip):

We have a test which prints debug stuff, but I only think it's a hello word example

davidtwco (Apr 15 2019 at 11:58, on Zulip):

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

davidtwco (Apr 15 2019 at 12:18, on Zulip):

I’m just not sure how to go about fixing it otherwise I’d have had a PR in.

pnkfelix (Apr 16 2019 at 08:16, on Zulip):

Hmm. One way is to generalize the printer to be able to handle cyclic graph structures

pnkfelix (Apr 16 2019 at 08:16, on Zulip):

But that’s a fair amount of effort

pnkfelix (Apr 16 2019 at 08:17, on Zulip):

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

Last update: Nov 22 2019 at 04:30UTC