5567: SSR: Wrap placeholder expansions in parenthesis when necessary r=matklad a=davidlattimore
e.g. `foo($a) ==> $a.to_string()` should produce `(1 + 2).to_string()` not `1 + 2.to_string()`
We don't yet try to determine if the whole replacement needs to be wrapped in parenthesis. That's harder and I think perhaps less often an issue.
Co-authored-by: David Lattimore <dml@google.com>
e.g. `foo($a) ==> $a.to_string()` should produce `(1 + 2).to_string()`
not `1 + 2.to_string()`
We don't yet try to determine if the whole replacement needs to be
wrapped in parenthesis. That's harder and I think perhaps less often an
issue.
5554: Fix remove_dbg r=matklad a=petr-tik
Closes#5129
Addresses two issues:
- keep the parens from dbg!() in case the call is chained or there is
semantic difference if parens are excluded
- Exclude the semicolon after the dbg!(); by checking if it was
accidentally included in the macro_call
investigated, but decided against:
fix ast::MacroCall extraction to never include semicolons at the end -
this logic lives in rowan.
Defensively shorten the macro_range if there is a semicolon token.
Deleted unneccessary temp variable macro_args
Renamed macro_content to "paste_instead_of_dbg", because it isn't a
simple extraction of text inside dbg!() anymore
Co-authored-by: petr-tik <petr-tik@users.noreply.github.com>
5563: Check all targets for package-level tasks r=matklad a=SomeoneToIgnore
When invoking "Select Runnable" with the caret on a runnable with a specific target (test, bench, binary), append the corresponding argument for the `cargo check -p` module runnable.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
replaced match with let-if variable assignment
removed the unnecessary semicolon_on_end variable
converted all code and expected test variables to raw strings
and inlined them in asserts
5572: Switch to ungrammar from ast_src r=matklad a=matklad
The primary advantage of ungrammar is that it (eventually) allows one
to describe concrete syntax tree structure -- with alternatives and
specific sequence of tokens & nodes.
That should be re-usable for:
* generate `make` calls
* Rust reference
* Hypothetical parser's evented API
We loose doc comments for the time being unfortunately. I don't think
we should add support for doc comments to ungrammar -- they'll make
grammar file hard to read. We might supply docs as out-of band info,
or maybe just via a reference, but we'll think about that once things
are no longer in flux
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
The primary advantage of ungrammar is that it (eventually) allows one
to describe concrete syntax tree structure -- with alternatives and
specific sequence of tokens & nodes.
That should be re-usable for:
* generate `make` calls
* Rust reference
* Hypothetical parser's evented API
We loose doc comments for the time being unfortunately. I don't think
we should add support for doc comments to ungrammar -- they'll make
grammar file hard to read. We might supply docs as out-of band info,
or maybe just via a reference, but we'll think about that once things
are no longer in flux
