@Luca Barbieri Could you elaborate on what the goal with https://github.com/rust-lang/rust/pull/70745 is?
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.
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.
@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
For testing, I'd suggest using the UI tests for the parser instead like
Yeah, I don't think you should perform such a replacement any time soon
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
Yes, some variation of that seems like it could be a good plan