| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
It's now consistent with other variables in that if the pattern
references self, only the `self` in scope where the rule is invoked will
be accepted. Since `self` doesn't work the same as other paths, this is
implemented by restricting the search to just the current function.
Prior to this change (since path resolution was implemented), having
self in a pattern would just result in no matches.
|
| |
|
|
|
| |
The selection is also used to avoid unnecessary work, but only to the
file level. Further restricting unnecessary work is left for later.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
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.
|
| |
|
|
| |
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.
|
| |
|
|
|
|
| |
Also renamed find_matches to slow_scan_node to reflect that it's a slow
way to do things. Actually the name came from a later commit and
probably makes more sense once there's an alternative.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we had:
- Multiple rules
- Each rule had its pattern parsed as an expression, path etc
This meant that there were two levels at which there could be multiple
rules.
Now we just have multiple rules. If a pattern can parse as more than one
kind of thing, then they get stored as multiple separate rules.
We also now don't have separate fields for the different kinds of things
that a pattern can parse as. This makes adding new kinds of things
simpler.
Previously, add_search_pattern would construct a rule with a dummy
replacement. Now the replacement is an Option. This is slightly cleaner
and also opens the way for parsing the replacement template as the same
kind of thing as the search pattern.
|
| | |
|
| |
|
|
|
| |
This is to make reusing it outside of parsing easier in a subsequent
change.
|
| | |
|
| |
|
|
| |
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).
|
| | |
|
| |
|
|
| |
Matching within macro calls is to come later and matching of macro calls within macro calls later still.
|
|
|
Part of #3186
|
