Commit graph

39 commits

Author SHA1 Message Date
Aleksey Kladov
6f8aa75329 Rename RecordLit -> RecordExpr 2020-07-30 16:21:30 +02:00
bors[bot]
51b18ee2f1
Merge #5587
5587: Finish use grammar r=matklad a=matklad

bors r+
🤖

Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2020-07-30 12:18:41 +00:00
Aleksey Kladov
9697d23cbe Rename UseItem -> Use 2020-07-30 14:12:04 +02:00
David Lattimore
fa1e411322 SSR: Wrap placeholder expansions in parenthesis when necessary
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.
2020-07-30 20:32:01 +10:00
Aleksey Kladov
6636f56e79 Rename ModuleItem -> Item 2020-07-30 00:23:03 +02:00
bors[bot]
9a9ddcc297
Merge #5564
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>
2020-07-29 09:23:33 +00:00
David Lattimore
fcb6b166fb SSR: Rename position and lookup_context to resolve_context 2020-07-29 19:20:40 +10:00
David Lattimore
3600c43f49 SSR: Don't mix non-path-based rules with path-based
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.
2020-07-29 16:01:00 +10:00
David Lattimore
cf55806257 SSR: Restrict to current selection if any
The selection is also used to avoid unnecessary work, but only to the
file level. Further restricting unnecessary work is left for later.
2020-07-29 15:06:58 +10:00
David Lattimore
b3ca36b2d9 SSR: Fix for path resolution of locals
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).
2020-07-26 21:58:35 +10:00
David Lattimore
bb587fae1d SSR: Move more resolution-related code into the resolving module 2020-07-26 21:58:35 +10:00
David Lattimore
3dac31fe80 SSR: Allow function calls to match method calls
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.
2020-07-24 21:34:00 +10:00
David Lattimore
8d09ab86ed SSR: Disable matching within use declarations
It currently does the wrong thing when the use declaration contains
braces.
2020-07-24 21:34:00 +10:00
David Lattimore
63f500b0ee SSR: Use Definition::find_usages to speed up matching.
When the search pattern contains a path, this substantially speeds up finding matches, especially if the path references a private item.
2020-07-24 21:34:00 +10:00
David Lattimore
757f755c29 SSR: Match paths based on what they resolve to
Also render template paths appropriately for their context.
2020-07-24 21:34:00 +10:00
David Lattimore
3975952601 SSR: Pass current file position through to SSR code.
In a subsequent commit, it will be used for resolving paths.
2020-07-24 21:34:00 +10:00
David Lattimore
02fc3d50ee SSR: Refactor to not rely on recursive search for nesting of matches
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.
2020-07-24 21:34:00 +10:00
David Lattimore
699619a65c SSR: Add a couple of tests for non-recursive search
These tests already pass, however once we switch to non-recursive
search, it'd be easy for these tests to not pass.
2020-07-24 21:34:00 +10:00
David Lattimore
6fcaaa1201 SSR tests: Define all paths needed for templates
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.
2020-07-24 21:34:00 +10:00
David Lattimore
a45682ed96 Move iteration over all files into the SSR crate
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.
2020-07-24 21:34:00 +10:00
David Lattimore
13f901f636 SSR: Move search code into a submodule
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.
2020-07-24 21:34:00 +10:00
David Lattimore
113abbeefe SSR: Parse template as Rust code.
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.
2020-07-24 21:34:00 +10:00
David Lattimore
1fce8b6ba3 SSR: Change the way rules are stored internally.
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.
2020-07-24 21:34:00 +10:00
David Lattimore
2b53639e38 SSR: Use expect! in tests 2020-07-24 21:34:00 +10:00
David Lattimore
a354e5b5cf SSR: Update tests so that all paths in patterns can be resolved 2020-07-04 08:56:58 +10:00
David Lattimore
69051d2f9d SSR: Refactor matching code.
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
2020-07-04 08:56:58 +10:00
David Lattimore
4a8679824b SSR: Improve error reporting when a test fails 2020-07-04 08:56:58 +10:00
David Lattimore
a5ef644a16 SSR: Extract error code out to a separate module
This is to make reusing it outside of parsing easier in a subsequent
change.
2020-07-04 08:56:51 +10:00
David Lattimore
83588a1c45 SSR: Use T! instead of SyntaxKind::* where possible 2020-07-02 09:19:58 +10:00
David Lattimore
3d9997889b SSR: Add initial support for placeholder constraints 2020-07-01 18:44:11 +10:00
David Lattimore
95f8310514 Structured search debugging 2020-07-01 16:50:45 +10:00
David Lattimore
ef49bbeec4 Fix some typos 2020-06-30 10:43:37 +10:00
bors[bot]
e1a5bd866e
Merge #5096 #5097
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 <dml@google.com>
2020-06-29 16:03:10 +00:00
Laurențiu Nicola
95d67ec401 Use more of FxHash* 2020-06-29 18:07:52 +03:00
David Lattimore
64a49589e7 Fix handling of whitespace when applying SSR within macro expansions.
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).
2020-06-27 20:38:31 +10:00
David Lattimore
fc46c12e36 Fix test following change to fixture parsing (d016cb4867) 2020-06-27 11:33:00 +10:00
David Lattimore
f4dc549582 SSR: Allow matching within macro calls 2020-06-27 11:33:00 +10:00
David Lattimore
467af611fb SSR: Allow matching of whole macro calls
Matching within macro calls is to come later and matching of macro calls within macro calls later still.
2020-06-23 07:42:34 +10:00
David Lattimore
662ab2ecc8 Allow SSR to match type references, items, paths and patterns
Part of #3186
2020-06-22 21:42:55 +10:00