I've almost nerdsnipped myself with this, but decided to write up an issue with mentoring instructions in the end: https://github.com/rust-analyzer/rust-analyzer/issues/2267 :)
@matklad https://github.com/google/rerast may help here, I'm transforming generated code with it these days.
@csmoe the idea is exactly to build rerast-like thin, but using rust-analyzer's types, which I believe I fundamentally more suitable for this kind of things in the limit (ie, when we finishing implementing all the things we yet have to add...)
How can I parse a String into an expr syntax tree node? And also, should ssr be performed on the concrete or abstract syntax tree?
SourceFile::parse in ra_syntax defines parsing of files
I think a similar method could be defined for
ast::Expr, but you'll need
parse_fragment function as an entry point
We don't have traditional AST (what is called
ast is, in fact, a typed concrete syntax tree)
So I think it makes sense to run ssr on concrete syntax tree, with maybe some hacks for more abstract comparison (like, not taking the order of fields into account, etc)
One more interesting bit is that, because replace bit has to happen at the CST level, you sort-of need to run the search on the CST as well
Ok thx, got it!
@Felix Kohlgrüber actually, I thik you can also use
make::expr_from_string -- it's hacky, but works
expr_from_text that is
ah ok, that should work. Thanks!
@matklad In the issue description, you wrote that writing a custom parser for the patterns might be better than using regex. Could you explain why you think so?
@matklad Ok so this is how mentions work. Sry, I'm new to zulip.
@Felix Kohlgrüber mainly because
regex is a big dependency. We have it in the crate graph already (which is regrettable, I believe at least two of the three uses are completely unnecessary) , but core crates like
ra_ide_api do not have this dependency
@matklad ok, sounds reasonable. I'll hand-roll my own ;-)