Autocomplete picks up module open inside line comments `//`.

[Benjamin San Souci]

I've added module String = Js.String2 at the top of my file of common stuff a really long time ago, and the autocomplete isn't picking up on it. It's still giving me the functions inside the stdlib String module.

[Cristiano Calcagno]

Seems to work for me, at least when tried on a standalone file.
Maybe this and other issues can investigated when the rescript-vscode extension with rescript-editor-support is released.
In general, the assumption is that everything has been built (typically there's a watcher).
Then autocomplete uses the information from the current build, plus the current file being edited.
So the file last saved must compile successfully (for module String = Js.String2 to be picked up), and the edit since saving would contain something like String..

So:

1. module String = Js.String2
2. save and build (or use a watcher)
3. edit String.
   Then autocomplete should work as expected.

[Cristiano Calcagno]

Closing as does not repro easily at the moment. Can be reopened with a new repro bases on latest release.

[Benjamin San Souci]

Hey, sorry for the silence, iOS work became high priority for a bit!
So I upgraded to 1.0.4, and I'm still having this issue.

Here are some steps I can use to repro every time. Before anything, you need to have your own module with module Array = { include Js.Array2; } (mine is called Common.res)

In a new file I just write this, and get the correct autocomplete:

Then I open Common and get the correct autocomplete:

But then the craziest thing happens, if I comment out open Common I still get the old autocomplete no matter what I do (I can restart vscode, and will get the same persistent issue).

Then I remove that commented out line, and everything goes back to normal.

Another, probably separate, issue that took me a while to track down is the following (small note, my code compiles and behaves correctly here, only autocomplete is having issues).
I have this function, parsing JSON and getting an object back. If I annotate data with anything (here string), I get correct autocomplete.

But if I annotate it with a generic 'a, I get incorrect autocomplete from that point in the code and below (within the same scope).

I think I did something along these lines, at the top level scope, which is why I'm getting issues at times. I'll work on removing these 'a, but since this all compiles fine I'm surprised that these runtime cast throw off the autocomplete.

[Cristiano Calcagno]

Here's what's going on. Autocomplete parses the source file simplistically backwards to look for open's. There's some logic to exclude /* stuff */ comments, but apparently not for line comments like:

// open Belt
List.

[Cristiano Calcagno]

For the second issue, it looks like single quotes are interpreted as string terminators, so 'a is interpreted as an unterminated string.

[Benjamin San Souci]

Thanks for fixing! Super appreciate it :)

[Cristiano Calcagno]

@bsansouci thank you for digging in and figuring out how to repro these corner cases.