Explore type based autocomplete #493
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| type someVariant = One | Two | Three | Four | ||
|
|
||
| let someVariantToString = (~someVariant) => | ||
| switch someVariant { | ||
| | One => "One" | ||
| | Two => "Two" | ||
| | Three => "Three" | ||
| | Four => "Four" | ||
| } | ||
|
|
||
| // let x = someVariantToString(~someVariant= | ||
| // ^com | ||
|
|
||
| module SomeComponent = { | ||
| @react.component | ||
| let make = (~whatever) => { | ||
| someVariantToString(~someVariant=whatever)->React.string | ||
| } | ||
| } | ||
|
|
||
| // let jsx = <SomeComponent whatever= | ||
| // ^com |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,3 +1,3 @@ | ||
| DCE src/Dce.res | ||
| issues:241 | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,12 @@ | ||
| Complete src/TypeContextCompletion.res 10:44 | ||
|
There was a problem hiding this comment. Let's see what's going on here first. But if you look at |
||
| posCursor:[10:44] posNoWhite:[10:43] Found expr:[10:11->18:1] | ||
|
There was a problem hiding this comment. Now, since the cursor in autocomplete is always after what you want to complete, we need to go back to find anything interesting. And eat up any white space. In this case, just one character back to There was a problem hiding this comment. We have hit an AST expression which goes from line Why so many lines? That's parser error recovery, which apparently is taking in also the module definition. |
||
| Pexp_apply ...[10:11->10:30] (~someVariant10:32->10:43=...[13:0->17:3]) | ||
|
There was a problem hiding this comment. Digging inside, we found a sub-expression that is an application. |
||
| Completable: CnamedArg(Value[someVariantToString], "", [someVariant]) | ||
|
There was a problem hiding this comment. So this is where it gets a bit hairy. Not sure why it decides it's a named arg completion given that it's in the expression assigned to the label. It could be because that expression is exactly where parser recovery happened and some heuristic is needed because of the uncertainty that parser recovery brings. Anyhow the There was a problem hiding this comment. OK looking at the code, I think we're hitting this case: | [] ->
if posAfterFunExpr <= posBeforeCursor && posBeforeCursor < endPos then
Some (CnamedArg (contextPath, "", allNames))So we went through the entire application and did not find anything interesting. So we'll just default to named arg completion. To see why this case is needed one can just turn it off and see what tests fail. |
||
| Found type for function (~someVariant: someVariant) => string | ||
|
There was a problem hiding this comment. Need to check where this is coming from: presumably named arg completion finding the type of the function. |
||
| [] | ||
|
There was a problem hiding this comment. As predicted, no result. |
||
|
|
||
| Complete src/TypeContextCompletion.res 20:37 | ||
| posCursor:[20:37] posNoWhite:[20:36] Found expr:[20:14->20:37] | ||
| JSX <SomeComponent:[20:14->20:27] whatever[20:28->20:36]=...__ghost__[0:-1->0:-1]> _children:None | ||
| [] | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should get rid of these differences. This is testing several things at once and it's not necessary.