| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Also render template paths appropriately for their context.
|
| |
|
|
| |
In a subsequent commit, it will be used for resolving paths.
|
| |
|
|
|
| |
These tests already pass, however once we switch to non-recursive
search, it'd be easy for these tests to not pass.
|
| |
|
|
|
|
|
| |
In a later commit, paths in templates will be resolved. This allows us
to render the path with appropriate qualifiers for its context. Here we
prepare for that change by updating existing tests where I'd previously
not bothered to define the items that the template referred to.
|
| |
|
|
| |
The methods `edits_for_file` and `find_matches_in_file` are replaced with just `edits` and `matches`. This simplifies the API a bit, but more importantly it makes it possible in a subsequent commit for SSR to decide to not search all files.
|
| |
|
|
|
|
| |
This is in preparation for a subsequent commit where we add special
handling for paths in the template, allowing them to be qualified
differently in different contexts.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
I originally did replacement by passing in the full file text. Then as some point I thought I could do without it. Turns out calling .text() on a node coming from a macro expansion isn't a great idea, especially when you then try and use ranges from the original source to cut that text. The test I added here actually panics without the rest of this change (sorry I didn't notice sooner).
|
| |
|
|
| |
(d016cb486738c1ab2574a322924183fa8a870b06)
|
| | |
|
| |
|
|
| |
Matching within macro calls is to come later and matching of macro calls within macro calls later still.
|
|
|
Part of #3186
|
