aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_ssr
Commit message (Collapse)AuthorAgeFilesLines
* Rename UseItem -> UseAleksey Kladov2020-07-301-1/+1
|
* SSR: Wrap placeholder expansions in parenthesis when necessaryDavid Lattimore2020-07-302-20/+111
| | | | | | | | | 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.
* Rename ModuleItem -> ItemAleksey Kladov2020-07-291-4/+1
|
* Merge #5564bors[bot]2020-07-295-47/+159
|\ | | | | | | | | | | | | | | 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]>
| * SSR: Rename position and lookup_context to resolve_contextDavid Lattimore2020-07-291-4/+4
| |
| * SSR: Restrict to current selection if anyDavid Lattimore2020-07-294-43/+155
| | | | | | | | | | The selection is also used to avoid unnecessary work, but only to the file level. Further restricting unnecessary work is left for later.
* | SSR: Don't mix non-path-based rules with path-basedDavid Lattimore2020-07-292-1/+62
|/ | | | 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.
* SSR: Fix for path resolution of localsDavid Lattimore2020-07-262-0/+65
| | | | | | | | 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).
* SSR: Move more resolution-related code into the resolving moduleDavid Lattimore2020-07-262-27/+38
|
* SSR: Allow function calls to match method callsDavid Lattimore2020-07-245-25/+166
| | | | | | | | | | | 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.
* SSR: Disable matching within use declarationsDavid Lattimore2020-07-242-1/+51
| | | | | It currently does the wrong thing when the use declaration contains braces.
* SSR: Use Definition::find_usages to speed up matching.David Lattimore2020-07-243-9/+133
| | | | When the search pattern contains a path, this substantially speeds up finding matches, especially if the path references a private item.
* SSR: Match paths based on what they resolve toDavid Lattimore2020-07-247-58/+469
| | | | Also render template paths appropriately for their context.
* SSR: Pass current file position through to SSR code.David Lattimore2020-07-243-22/+54
| | | | In a subsequent commit, it will be used for resolving paths.
* SSR: Refactor to not rely on recursive search for nesting of matchesDavid Lattimore2020-07-244-27/+120
| | | | | | | | | 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.
* SSR: Add a couple of tests for non-recursive searchDavid Lattimore2020-07-241-0/+33
| | | | | These tests already pass, however once we switch to non-recursive search, it'd be easy for these tests to not pass.
* SSR tests: Define all paths needed for templatesDavid Lattimore2020-07-241-26/+76
| | | | | | | 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.
* Move iteration over all files into the SSR crateDavid Lattimore2020-07-244-47/+77
| | | | 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.
* SSR: Move search code into a submoduleDavid Lattimore2020-07-242-48/+56
| | | | | | 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.
* SSR: Parse template as Rust code.David Lattimore2020-07-245-82/+112
| | | | | | 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.
* SSR: Change the way rules are stored internally.David Lattimore2020-07-244-107/+123
| | | | | | | | | | | | | | | | | | | | | | 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.
* SSR: Use expect! in testsDavid Lattimore2020-07-242-37/+37
|
* SSR: Update tests so that all paths in patterns can be resolvedDavid Lattimore2020-07-031-67/+97
|
* SSR: Refactor matching code.David Lattimore2020-07-031-80/+75
| | | | | | Mutable state is now stored in the enum Phase. MatchState, since it now has no mutable state is renamed Matcher. MatchInputs is merged into Matcher
* SSR: Improve error reporting when a test failsDavid Lattimore2020-07-032-21/+36
|
* SSR: Extract error code out to a separate moduleDavid Lattimore2020-07-033-23/+35
| | | | | This is to make reusing it outside of parsing easier in a subsequent change.
* SSR: Use T! instead of SyntaxKind::* where possibleDavid Lattimore2020-07-021-11/+11
|
* SSR: Add initial support for placeholder constraintsDavid Lattimore2020-07-014-6/+143
|
* Structured search debuggingDavid Lattimore2020-07-014-160/+207
|
* Fix some typosDavid Lattimore2020-06-303-5/+5
|
*-. Merge #5096 #5097bors[bot]2020-06-294-18/+37
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5096: Fix handling of whitespace when applying SSR within macro expansions. r=matklad a=davidlattimore 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). 5097: Fix SSR prompt following #4919 r=matklad a=davidlattimore Co-authored-by: David Lattimore <[email protected]>
| * | Fix handling of whitespace when applying SSR within macro expansions.David Lattimore2020-06-274-18/+37
| |/ | | | | | | 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).
* / Use more of FxHash*Laurențiu Nicola2020-06-291-1/+1
|/
* Fix test following change to fixture parsing ↵David Lattimore2020-06-271-1/+11
| | | | (d016cb486738c1ab2574a322924183fa8a870b06)
* SSR: Allow matching within macro callsDavid Lattimore2020-06-273-2/+69
|
* SSR: Allow matching of whole macro callsDavid Lattimore2020-06-224-13/+173
| | | | Matching within macro calls is to come later and matching of macro calls within macro calls later still.
* Allow SSR to match type references, items, paths and patternsDavid Lattimore2020-06-226-0/+1456
Part of #3186
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-26 20:01:08 +0000