-
Notifications
You must be signed in to change notification settings - Fork 95
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
Add message-format=json support #53
Conversation
For my sanity's sake, I'm currently working on fixing serde-rs/serde#912. This will allow turning Message into enum Message {
CompilerArtifact(Artifact),
CompilerMessage(FromCompiler),
BuildScript(BuildScriptExecution),
#[doc(hidden)]
#[serde(other)]
Unknown
} Blocking on serde-rs/serde#1382 |
@@ -0,0 +1,118 @@ | |||
//! This module contains `Diagnostic` and the types/functions it uses for deserialization. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file should be shared with rustfix in some manner
cc @killercup
Serde 1.0.79 is released, and with it #[serde(other)] is now available. I pushed a commit updating the serde dep to reflect that. Question: Should all enums currently having a This is what it would change: // Before
assert!(serde_json::from_str::<DependencyKind>(r#" "unknown" "#).is_error());
// After
assert_eq!(serde_json::from_str::<DependencyKind>(r#" "unknown" "#),
Ok(DependencyKind::Unknown)); The Unknown arm would still be #[doc(hidden)]'d, so the user would have to use the catchall to match it. |
I just tried the branch and I really like it. It makes a nice improvements over my earlier self-written structs, esp. with One thing that would be useful is a |
/// The enabled features for this artifact | ||
pub features: Vec<String>, | ||
/// The full paths to the generated artifacts | ||
pub filenames: Vec<String>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might those be better as PathBuf than as String?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought so too, but cargo_metadata uses String in places where PathBuf makes more sense, e.g.
Line 152 in 54a24e3
pub workspace_root: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Imho workspace_root should also be changed, but maybe in a different PR. @oli-obk What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@konstin Oliver is away until October.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember trying PathBuf
in more places, but then ending up with errors because not everything must be a path. For these two cases it seems fine though.
//! .stdout(Stdio::piped()) | ||
//! .spawn().unwrap(); | ||
//! | ||
//! for message in cargo_metadata::parse_message_stream(command.stdout.unwrap()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Imo this example should .take()
before unwrapping. Otherwise you can't wait for the command to finish afterwards.
The Option<> around rendered comes from the structs defined in Rustc. I think it only happens in children though, the root seems to always have a rendered message. E.G. https://github.com/rust-lang/rust/blob/215bf3abd9c0eb1fd0c6cae7c92a842732dc033d/src/test/ui/lint/unused_parens_json_suggestion.stderr#L60 . ToString might be a good idea. Display also. I was also planning on writing a EDIT: While ToString/Display might come in this PR if it's desirable, the print function will likely come with another PR, as I don't have the time to work on it right now. |
seems ok. It's more useful to get a partial parse than an error if new thing are added to the enums on the rustc/cargo side |
What would be required to get this merged and released on crates.io? I'm using those types in pyo3-pack and would like to release on crates.io without vendoring tricks. |
I'll get around to addressing all the comments in the PR tomorrow (Using PathBuf, changing enums into |
Inspired by oli-obk/cargo_metadata#53 This allowed `CargoRun` to improve the logged output.
/// The associated error code for this diagnostic | ||
pub code: Option<DiagnosticCode>, | ||
/// "error: internal compiler error", "error", "warning", "note", "help" | ||
pub level: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason this isn't an enum?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the same could be said for cargo-metadata
s existing kind
, crate_types
, opt_levels
, and anywhere else supported values are documented in a comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, this was mostly chose for forward compatibility
I've forked this in my PR for escargot Main differences
In addition, I went ahead and forked |
Inspired by oli-obk/cargo_metadata#53 This allowed `CargoRun` to improve the logged output.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've forked this in my PR for escargot
Maybe we should create a library-only crate that exposes the shared types?
/// An iterator of Message. | ||
type MessageIterator<R> = serde_json::StreamDeserializer<'static, serde_json::de::IoRead<R>, Message>; | ||
|
||
// TODO: Should I use de::Read instead, to support deserializing from a slice? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's strictly more powerful to use de::Read
, then by all means
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On investigating this a bit, de::Read isn't very convenient. It's implemented on serde_json::de::IoRead
, serde_json::de::SliceRead
, etc... and not on the actual libstd. Besides, I have a hard time envisioning under which situation would someone try to read an array of cargo messages from a byte array instead of an std::io::Read...
I'll remove the TODO.
|
||
// TODO: Should I use de::Read instead, to support deserializing from a slice? | ||
/// Creates an iterator of Message from a Read outputting a stream of JSON | ||
/// messages. For usuage information, look at the top-level documentation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// messages. For usuage information, look at the top-level documentation. | |
/// messages. For usage information, look at the top-level documentation. |
/// The associated error code for this diagnostic | ||
pub code: Option<DiagnosticCode>, | ||
/// "error: internal compiler error", "error", "warning", "note", "help" | ||
pub level: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, this was mostly chose for forward compatibility
Superseded by #64 |
Fixes #45
Most of the structs come directly from cargo or rustc. This is not ready yet, there are a few things that need to be done. Most importantly, the enums (mostly Message) need to have a catch-all variant so that it won't break if new variants are added. Also, I think we'd do well to change the names of some structs here and there.
Also, I need to add some tests and fix the doctest example.