This commit fixes the handling of user-defined configuration
of some cargo options. Previously you could either specify
`--all-features`, `--no-default-features` or `--features`.
Now you can specify either `--all-features` or `--no-default-features`
and `--features`. This commit also corrects the `--features`
command-line argument creation inside of `load_extern_resources`.
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
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
5564: SSR: Restrict to current selection if any r=davidlattimore a=davidlattimore
The selection is also used to avoid unnecessary work, but only to the file level. Further restricting unnecessary work is left for later.
Co-authored-by: David Lattimore <dml@google.com>
5565: SSR: Don't mix non-path-based rules with path-based r=matklad a=davidlattimore
If any rules contain paths, then we reject any rules that don't contain paths. Allowing a mix leads to strange semantics, since the path-based rules only match things where the path refers to semantically the same thing, whereas the non-path-based rules could match anything. Specifically, if we have a rule like `foo ==>> bar` we only want to match the `foo` that is in the current scope, not any `foo`. However "foo" can be parsed as a pattern (BIND_PAT -> NAME -> IDENT). Allowing such a rule through would result in renaming everything called `foo` to `bar`. It'd also be slow, since without a path, we'd have to use the slow-scan search mechanism.
Co-authored-by: David Lattimore <dml@google.com>
If any rules contain paths, then we reject any rules that don't contain paths. Allowing a mix leads to strange semantics, since the path-based rules only match things where the path refers to semantically the same thing, whereas the non-path-based rules could match anything. Specifically, if we have a rule like `foo ==>> bar` we only want to match the `foo` that is in the current scope, not any `foo`. However "foo" can be parsed as a pattern (BIND_PAT -> NAME -> IDENT). Allowing such a rule through would result in renaming everything called `foo` to `bar`. It'd also be slow, since without a path, we'd have to use the slow-scan search mechanism.
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
It seems that Semantics::scope, if given a statement node, won't resolve
locals that were defined in the current scope, only in parent scopes.
Not sure if this is intended / expected behavior, but we work around it
for now by finding another nearby node to use as the scope (e.g. the
expression inside the EXPR_STMT).
5520: Add DocumentData to represent in-memory document with LSP info r=matklad a=kjeremy
At the moment this only holds document version information but in the near-future it will hold other things like semantic token delta info.
Co-authored-by: kjeremy <kjeremy@gmail.com>
5522: Increace tracing-tree version from 0.1.3 to 0.1.4 r=kjeremy a=vandenheuvel
Co-authored-by: Bram van den Heuvel <b.vandenheuvel@student.tudelft.nl>
5516: Better LSP conformance r=matklad a=vsrs
At the moment rust-analyzer does not fully conform to the LSP. This PR fixes two LSP related issues:
1) rust-analyzer sends predefined server capabilities and does not take supplied client capabilities in mind.
2) rust-analyzer uses dynamic `textDocument/didSave` registration even if the client does not support it.
Co-authored-by: vsrs <vit@conrlab.com>
5518: Use resolved paths in SSR rules r=matklad a=davidlattimore
The main user-visible changes are:
* SSR now matches paths based on whether they resolve to the same thing instead of whether they're written the same.
* So `foo()` won't match `foo()` if it's a different function `foo()`, but will match `bar::foo()` if it's the same `foo`.
* Paths in the replacement will now be rendered with appropriate qualification for their context.
* For example `foo::Bar` will render as just `Bar` inside the module `foo`, but might render as `baz::foo::Bar` from elsewhere.
* This means that all paths in the search pattern and replacement template must be able to be resolved.
* It now also matters where you invoke SSR from, since paths are resolved relative to wherever that is.
* Search now uses find-uses on paths to locate places to try matching. This means that when a path is present in the pattern, search will generally be pretty fast.
* Function calls can now match method calls again, but this time only if they resolve to the same function.
Co-authored-by: David Lattimore <dml@google.com>
This differs from how this used to work before I removed it in that:
a) It's only one direction. Function calls in the pattern can match
method calls in the code, but not the other way around.
b) We now check that the function call in the pattern resolves to the
same function as the method call in the code.
The lack of (b) was the reason I felt the need to remove the feature
before.
