-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
capture diagnostic output in queries #42513
Comments
No need! Everything already passes |
@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 |
I am aware of nothing that has |
@eddyb the point is that if you have the methods available on |
Then we can have the query engine mess with the |
@eddyb yes that would be fine |
This commit alters the `rustc::ty::maps` implementation to ensure that all output diagnostics from the compiler are tracked for the duration of each query. These are then intended to be replayed back the first time a cached value is loaded, and otherwise the cache should operate the same as it does today. Closes rust-lang#42513
…rister rustc: Capture diagnostics from all queries This commit alters the `rustc::ty::maps` implementation to ensure that all output diagnostics from the compiler are tracked for the duration of each query. These are then intended to be replayed back the first time a cached value is loaded, and otherwise the cache should operate the same as it does today. Closes #42513
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_err
and 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.
The text was updated successfully, but these errors were encountered: