FCS 43.7.200 has odd behavior for modules with errors

[baronfel]

While updating FsAutoComplete to support F# 7 I found that something fundamental has changed in the way at least anonymous modules are parsed in the presence of errors. This leads to a large number of parse-tree-based helper methods for powering codefixes no longer functioning, and so many of the tests FSAC has validating codefix behavior are now permanently broken. For the codefixes I've directly investigated that have parallels in the VS tooling in this repo, I saw the same behavior using a VS 17.5 preview (to ensure I was on a similar FCS). Let's dig into one CodeFix in particular - the one that converts erroring single-quote string interpolation into triple-quoted interpolation.

Repro steps

Provide the steps required to reproduce the problem:

1. Load up an .fsx file with the following content: let a = $":^) {if true then "y" else "n"} d"
2. Note that a diagnostic 3373 is triggered at the " next to the y.
3. Attempt to fire a codefix - none is found.
4. The code that should trigger the codefix is TryRangeOfStringInterpolationContainingPos
5. TryRangeOfStringInterpolationContainingPos isn't finding an interpolated string expression, why?
6. There are no decls in the SynModuleOrNamespace:
   

This is the case for many other codefixes, and they present the same way in VS as well.

[vzarytovskii]

@nojaf @auduchinok does this ring a bell to you? I remember some changes around modules.

[vzarytovskii]

@baronfel in case if I need to bisect it, what would you say will be the fastest way of doing it? Do you have a FCS api snippet by any chance?

[baronfel]

You should be able to debug it using the code string above and breakpointing here - VS has a codefix for interpolation as well (which is why I used it as the example). But the sample overall would be very simplistic:

• create a script file/sourcetext with that content and get ProjectOptions for a script from FCS
• parse the file
• try to call the TryRangeOfStringInterpolationContainingPos API using the start position of the diagnostic returned by the parse
• you get None, but you should get Some range.

[auduchinok]

@nojaf @auduchinok does this ring a bell to you? I remember some changes around modules.

Nope, sorry. Maybe it could be related to PRs like #14399 or #14434?

[nojaf]

This doesn't ring a bell, all I can say is that is happened between 7d115d5 and e30d14c.

[nojaf]

Maybe #14182 is related. @abonie any thoughts?

[abonie]

Yes, it looks like the root cause as far as I can tell (idk how code fixes work, but second comment in that PR thread might explain how it broke it)

[0101]

The change that caused this was reverted (but not backported to 17.5). It should work in 17.6.