Add -Zerror-metrics=PATH to save diagnostic metadata to disk
#119355
Conversation
|
(rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
estebank
force-pushed
the
error_metrics
branch
from
3dfb6d3
to
ef75451
Compare
Add nightly only flag to store information about encountered errors to disk. The information being tracked is: - Error code - Path to error being emitted - Number of subdiagnostics - Number of structured suggestions
estebank
force-pushed
the
error_metrics
branch
from
ef75451
to
2ab3cb9
Compare
| if let Some(ref mut file) = &mut self.metrics { | ||
| let _ = writeln!( | ||
| file, | ||
| "{:?},{:?},{},{}", |
There was a problem hiding this comment.
Why are we using this custom format when we already have JSON diagnostic output?
Even if we shouldn't be emitting as much info as JSON-formatted diagnostics, we should perhaps make it easier for arbitrary programs to consume by formatting it like JSON.
| let metrics = sopts.unstable_opts.error_metrics.as_ref().and_then(|path| { | ||
| let mut path = path.clone(); | ||
| std::fs::create_dir_all(&path).ok()?; | ||
| path.push(format!("error_metrics_{}", std::process::id())); |
There was a problem hiding this comment.
Why PID? Can we use something more ordered such as YYYY-MM-DD-HH-SS-PID?
|
Does this need to be in rustc? What is the intended consumption workflow (is there intent to stabilize this)? I would expect that ~all of this information is already available to programs running rustc with errors emitted as JSON (e.g., Cargo) and they could handle aggregating and propagating that information. |
|
☔ The latest upstream changes (presumably #119621) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@rustbot author |
rustbot
added
S-waiting-on-author
|
@estebank any updates on this? thanks |
Add nightly only flag to store information about encountered errors to disk. The information being tracked is: