Skip to content
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

save-analysis: dump in JSON format #33208

Merged
merged 7 commits into from
Apr 28, 2016
Merged

save-analysis: dump in JSON format #33208

merged 7 commits into from
Apr 28, 2016

Conversation

nrc
Copy link
Member

@nrc nrc commented Apr 25, 2016

cc #18582

nrc added 6 commits April 25, 2016 18:49
...in which we make the spans nice.
In fact, we make JSOn the default and add an option for save-analysis-csv for the legacy behaviour.

We also rename some bits and pieces `dxr` -> `save-analysis`
@rust-highfive
Copy link
Collaborator

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

fn use_data(&mut self, UseData);
fn use_glob(&mut self, UseGlobData);
fn variable(&mut self, VariableData);
fn variable_ref(&mut self, VariableRefData);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The advantage of default methods is that you can easily implement a dumper that dumps only a subset of the data. For instance, in RRT there is a dumper for collecting data about glob imports that only implements the use_glob method.

If there is no strong reason to change it, I would rather keep the default methods.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Methods which are empty by default are trivial to implement, so there is not much advantage to not having to write them out. On the other hand, if we have defaults and we add another, then any implementers will be silently broken. With required methods, the compiler tells us we have to fix the impls.

On the other hand, I can see that if you just want (e.g.) globs, then it is painful to write out all the other methods. I guess Rust wants more nuanced inheritance for this kind of thing. I'll revert this change.

@pnkfelix
Copy link
Member

@nrc I've only started looking at the first commit, so maybe this Q is resolved later in the series, but: In removing the dump spans stuff, is your intention that spans should not be part of any serialized output? Or do the spans come back later in a different form?

@nrc
Copy link
Member Author

nrc commented Apr 26, 2016

@pnkfelix dump spans was an old hack for just dumping spans of AST nodes without any other data. I only ever used it for debugging and it has no users, afaik. The stuff I removed is not really related to the rest of save-analysis, the spans are still there as part of the data structs.

@pnkfelix
Copy link
Member

@nrc oh okay I misunderstood the role of "dump spans", thanks for the clarification.

@pnkfelix
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Apr 27, 2016

📌 Commit 129c3bb has been approved by pnkfelix

@bors
Copy link
Contributor

bors commented Apr 27, 2016

⌛ Testing commit 129c3bb with merge e3c0c09...

@bors
Copy link
Contributor

bors commented Apr 27, 2016

💔 Test failed - auto-linux-64-opt-rustbuild

@nrc
Copy link
Member Author

nrc commented Apr 27, 2016

@bors r=pnkfelix

@bors
Copy link
Contributor

bors commented Apr 27, 2016

📌 Commit 7ca2b94 has been approved by pnkfelix

@bors
Copy link
Contributor

bors commented Apr 28, 2016

⌛ Testing commit 7ca2b94 with merge 4751e45...

bors added a commit that referenced this pull request Apr 28, 2016
save-analysis: dump in JSON format

cc #18582
@aochagavia
Copy link
Contributor

@nrc I like the fact that you created new structs which are decoupled from the compiler's internals. This makes working with spans much easier. Would it make sense to feed Dump's methods with these structs?

For instance:

pub trait Dump {
    fn crate_prelude(&mut self, CratePreludeData) {}
   ...
}

Could become:

pub trait Dump {
    fn crate_prelude(&mut self, json_dumper::CratePreludeData) {}
   ...
}

Maybe we could also extract the *Data types to their own module.

A concrete benefit of this is that the lowering code only needs to be written one time and can be shared across multiple save_analysis backends (json, csv, etc).

@nrc
Copy link
Member Author

nrc commented May 1, 2016

@aochagavia I had thought about this, and think it would be an improvement. However, I also have an alternate approach in mind (although not fully fleshed out):

I would like that rather than have a Dump trait, we can implement a serialiser for each format. This is how JSON works - we start with the internal data, lower to 'external' data then serialise to JSON and the implementation of the Dump trait is just a dumb wrapper. I don't know exactly what a CSV serialiser would look like, so I'm not sure if it would run off the same external data, if it could, that would be ideal, but I think it would more likely look a bit different, in which case we would have the internal format, and then lower that to either the JSON or CSV flavour of the external data and then serialise that. That is a bit nasty. And it begs the question what should the API return? At the moment, the API needs the internal data because we look at the spans, etc., but ideally I think it should return an external format (and everything runs off that).

I guess moving the Dump trait to using the JSON/external data could be viewed as a step towards a serialiser - thinking more about it, it seems like a step in the right direction.

I plan to discuss the long term plans for save-analysis with the rest of the compiler team next week, so there will probably be more input then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants