Stream: t-compiler

Topic: #70745 - parsing with rust-analyzer instead of librustc_pars

centril (Apr 03 2020 at 22:45, on Zulip):

@Luca Barbieri Could you elaborate on what the goal with is?

centril (Apr 03 2020 at 22:47, on Zulip):

I don't think we discussed replacing rustc_parse (which there is nothing wrong with, and which has been reviewed and refactored in-depth by now) with a whole other crate in the design meeting, only making tweaks to the existing parser to fit RA better.

Luca Barbieri (Apr 04 2020 at 11:24, on Zulip):

it was mostly a fun project, although it can be used to test the rust-analyzer parser against the rustc one by comparing the output of -Z ast-json-noexpand with and without the -Z parse-with-rust-analyzer flag. It could also be used in principle to delete the rustc parser from the repository and use the RA parser in stable rustc, but that would require major effort on the RA parser; or it could be used to change the rustc parser to output the rust-analyzer parsing events, use the code in the pull request to create the rustc data structures and delete the RA parser, not sure about the effort required for that.

centril (Apr 04 2020 at 14:13, on Zulip):

@Luca Barbieri I see -- I think we shouldn't be entertaining replacing rustc_parse with a new one, as that is a high risk project, and the current parser is already a good one

centril (Apr 04 2020 at 14:13, on Zulip):

For testing, I'd suggest using the UI tests for the parser instead like syn does

Luca Barbieri (Apr 04 2020 at 14:14, on Zulip):

Yeah, I don't think you should perform such a replacement any time soon

centril (Apr 04 2020 at 14:19, on Zulip):

To accommodate RA; I think it would be best to tweak rustc_parse to emit some generically chosen (as in associated types) AST nodes, which for RA would be "parsing events" and for rustc would be rustc_ast

Luca Barbieri (Apr 04 2020 at 14:45, on Zulip):

Yes, some variation of that seems like it could be a good plan

Last update: May 29 2020 at 17:55UTC