"Go To Definition" resolves to promise when in async scope

[youngkidwarrior]

When there is a compiler error,
Any modules or function in an async scope will resolve to the promise definition when
Shift + click or Right Click -> Go to definition

Example:

Screen.Recording.2023-10-26.at.5.36.20.PM.mov

[cristianoc]

Seems likely the location of the promise wrapper used to return a promise type "covers" the rest of the program.

Does this happen on the latest beta of the compiler?
And is there any similar issue when the compiler reports a type error?

I thought there was a fix for something like this but might be misremembering CC @zth

[youngkidwarrior]

yes it's the latest beta "rc.4"

It's actually been happening to me since Rescript 10 beta when support for async/await landed. Just haven't gotten around to reporting it till now lol

[zth]

Would it be possible for you to set up a minimal reproduction?

[youngkidwarrior]

@zth I can, but, just to check,
does "Go to definition" work for you in async functions while the compiler has an error?

Go into any async function you have and change it to have an error, then shift click a module. Does it work for you?

If it does work for you then it is probably an issue with my local machine

[zth]

I've seen this before too, yes. So a reproduction would be good.

[youngkidwarrior]

@zth

Check Demo.res
https://github.com/youngkidwarrior/async-gtd-fail-example

[cristianoc]

If "compiler error" means "parse error" then there's little one can expect.
If there's a repro for code that parses and gives a type error, then it's possible to investigate more.

[zth]

@cristianoc the repo misses ending ) for each line to uncomment. Add that and the type error and issue surfaces.

[youngkidwarrior]

The missing ) was to demonstrate that not only the await keyword causes the problem, but any type error does

[zth]

@youngkidwarrior point is that it's not a type error when ) is missing but a parse error, and those are handled quite differently.

[zth]

But yeah, if the problem lies in the body definition itself I guess you're right that that also demonstrates the issue independently of whether it's a parse or type error, as the location seems to get messed up regardless.

[zth]

Fixed in the compiler.