| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
| |
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
| | |
|
| |
| |
| |
| |
| | |
The selection is also used to avoid unnecessary work, but only to the
file level. Further restricting unnecessary work is left for later.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
| |/
| |
| |
| | |
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.
|
|/ |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5547: Fold multiline fn parameters r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
5532: Restore line index optimization for edits r=matklad a=lnicola
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
5539: SSR: Fix path resolution of locals in current scope r=matklad a=davidlattimore
Co-authored-by: David Lattimore <[email protected]>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
5524: Allow opting out of experimental diagnostics like MismatchedArgCount r=matklad a=jonas-schievink
Closes https://github.com/rust-analyzer/rust-analyzer/issues/5448
Closes https://github.com/rust-analyzer/rust-analyzer/issues/5419
Co-authored-by: Jonas Schievink <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
This reverts commit 5b13c2411f025a16495f5828afe2def6e9220102, reversing
changes made to c3defe2532ba6ffd12a13bcbc8fdeda037665efc.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
5522: Increace tracing-tree version from 0.1.3 to 0.1.4 r=kjeremy a=vandenheuvel
Co-authored-by: Bram van den Heuvel <[email protected]>
|
| | | | |
|
|\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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 <[email protected]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
|\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | | |
It currently does the wrong thing when the use declaration contains
braces.
|
| | |
| | |
| | |
| | | |
When the search pattern contains a path, this substantially speeds up finding matches, especially if the path references a private item.
|
| | |
| | |
| | |
| | | |
Also render template paths appropriately for their context.
|
| | |
| | |
| | |
| | | |
In a subsequent commit, it will be used for resolving paths.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, submatches were handled simply by searching in placeholders
for more matches. That only works if we search all nodes in the tree
recursively. In a subsequent commit, I intend to make search not always
be recursive recursive. This commit prepares for that by finding all
matches, even if they overlap, then nesting them and removing
overlapping matches.
|
| | |
| | |
| | |
| | |
| | | |
These tests already pass, however once we switch to non-recursive
search, it'd be easy for these tests to not pass.
|