Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upcapture diagnostic output in queries #42513
Comments
nikomatsakis
added
A-incr-comp
E-hard
E-mentor
T-compiler
labels
Jun 7, 2017
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
No need! Everything already passes |
This comment has been minimized.
This comment has been minimized.
|
@eddyb well, we issue diagnostics directly on the session sometimes, when the tcx is not available yet, right? I was nervous about that. At minimum, we'd have to move the methods to some new place, so that we can be sure that all existing code uses the |
This comment has been minimized.
This comment has been minimized.
|
I am aware of nothing that has |
This comment has been minimized.
This comment has been minimized.
|
@eddyb the point is that if you have the methods available on |
This comment has been minimized.
This comment has been minimized.
|
Then we can have the query engine mess with the |
This comment has been minimized.
This comment has been minimized.
|
@eddyb yes that would be fine |
nikomatsakis commentedJun 7, 2017
Right now, queries produce results, but as a side-effect they may issue diagnostics. For incremental compilation, if we are going to (e.g.) skip typeck, but still produce the same output, we really need to capture this output so that we can replay it.
Right now, to issue a diagnostic, you basically directly invoke methods on the session, such as
span_errand friends. Whenemit()is called, these just directly dump out to stderr.To fix this issue, we would want to record those diagnostics. There is already a diagnostics object that is created (and thus can in principle be saved) -- but we'd have to find the right place to save it (in the query tables, presumably).
We also have to figure out how to recover the tcx. The easiest way to handle this would be to check the TLS for the current tcx (using
ty::tls::with()) and record it that way. We generally discourage using TLS to get the tcx except in specific scenarios, but this may fall under that category.I'm tagging this for mentoring without instructions. There is still some amount of pending design work here that will require experimentation. Plus, once the work is done, we'll have to figure out (separately) how to actually save the errors to disk and replay them etc.