Skip to content

Use serialisation for save_analysis #18582

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

Closed
nrc opened this issue Nov 3, 2014 · 16 comments
Closed

Use serialisation for save_analysis #18582

nrc opened this issue Nov 3, 2014 · 16 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue.

Comments

@nrc
Copy link
Member

nrc commented Nov 3, 2014

Currently we use an ad hoc csv format for dumping analysis data (see rustc::middle::save::recorder). It would be better to use libserialize (or serde) for the dumping step so we can easily provide data in different formats.

By default, I think save_analysis should output JSON, since that seems to be the current hotness for this sort of thing.

I expect this to be not too hard, but non-trivial, and possibly a little bit tedious.

@nrc nrc added A-tools E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. labels Nov 3, 2014
@sinistersnare
Copy link
Contributor

cc me

@gamazeps
Copy link
Contributor

gamazeps commented Nov 4, 2014

Willing to work on this too :)

@gamazeps
Copy link
Contributor

gamazeps commented Nov 5, 2014

@sinistersnare Wanna split the work ? Or did you cc just in order to see the progress ?

@sinistersnare
Copy link
Contributor

Sure. this could be interesting.

@rolandshoemaker
Copy link

Is this still being worked on or abandoned?

@nrc
Copy link
Member Author

nrc commented Jan 6, 2015

@sinistersnare @gamazeps ? (See previous comment)

@sinistersnare
Copy link
Contributor

Oh goodness, I forgot about this :)

I can start work on this next week, but if you want to take this @rolandshoemaker, than feel free. Sorry!

@Potpourri
Copy link
Contributor

I would like to work on this.

@sinistersnare
Copy link
Contributor

Please do, I have no more plans of contributing.

@Potpourri
Copy link
Contributor

@nick29581 Do I need to keep csv support?

@nrc
Copy link
Member Author

nrc commented Feb 5, 2015

@Potpourri tl;dr: no.

What would be ideal would be to have a generic serialisation API which could serialise to JSON, CSV or whatever else. I'm not sure if that is possible or how easy it is (@erickt might be able to advise). I'd be pretty happy with just JSON, as long as it wasn't too hard-wired in. (You could also earn mega-love from me by converting DXR to understand JSON rather than CSV as a follow up, but I'm also happy to do that).

@steveklabnik
Copy link
Member

Triage: looks like we're still using the CSV format.

@aochagavia
Copy link
Contributor

In #31838, I introduced the Dump trait as a first step to closing this issue (see the internal docs). Outputting JSON should be as simple as creating a new implementor of Dump that dumps everything as JSON instead of CSV.

For inspiration, see csv_dumper.rs.

@nrc
Copy link
Member Author

nrc commented Apr 25, 2016

I have a PR done now which adds JSON emission. It uses serialisation for that, but it doesn't really fix this issue. I would like to see save-analysis refactored so that rather than using the Dumper trait, we use a lowering step from internal data to external data (this is done for JSON, but not CSV) rather than using span utils and so forth. Then we shouldn't need a dumper at all, just take the external data structs and serialise them suing the serialiser of your choice.

We should also use these 'external' data structures for the API, rather than exposing the internal ones like we do at the moment.

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

cc #18582
@alexcrichton alexcrichton added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. and removed T-tools labels May 22, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 22, 2017
@tamird
Copy link
Contributor

tamird commented Apr 8, 2018

Looks like a bunch of this was done in 9a47160. @nrc is there anything left?

@nrc
Copy link
Member Author

nrc commented Apr 8, 2018

Oh yeah, this is all done now, thanks!

@nrc nrc closed this as completed Apr 8, 2018
bors pushed a commit that referenced this issue Apr 9, 2018
...it was removed in 9a47160.

Updates #18582.
bors added a commit that referenced this issue Apr 9, 2018
Remove mention of CsvDumper

...it was removed in 9a47160.

Updates #18582.

r? @nrc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

10 participants