FS0039 does not go away, even after rebuilding, commenting out, while compilation is successful

[abelbraaksma]

VS 2017, 15.3.1.0, Preview 1 (18 August 2017 version).

I'm a bit stymied by this. I have seen "sticky errors" before, but usually clean > rebuild or open/close the offending file, or editing it makes it go away. However, this syntax error is sticky and the only thing I haven't done is close/reopen the solution (this probably helps, but while the error is out there, and someone responding/looking into this wants me to analyse some more, I keep it open).

Here's is the error in an empty area after commenting it out:

Please note that the solution builds successfully, from clean or otherwise, on build-server, from commandline and from Visual Studio.

Repro steps

Honestly, I don't know how to repro this with a small enough example. I haven't seen it in a while, though previous VS Preview versions did have similar issues.

The error started after I renamed the called function, which wasn't yet renamed on the call site, causing the error (a common practice: rename, or try to let VS rename for you, then rebuild, find errors that auto-rename didn't fix (usually: auto-rename finds none anyway), fix, then rebuild).

Expected behavior

If a solution builds successfully, the error should not be shown anymore.

Actual behavior

Whatever I try, the error remains.

Note that this was originally a "real" error. The actual function it reports on is in the same project. The function it reports on is itself inlined and uses function composition, but that is used all over the place anyway.

Known workarounds

Possibly restarting VS2017 helps, or manually cleaning any files that have not been cleaned from the Clean Build command. But short of restarting, I'd be happy to hear from anybody a suitable workaround.

My gut feeling says that this is in the "in memory" TAST or whatever that part is called and does not get cleaned for some reason.

Things that did not work:

• Building successfully
• Changing source code up to the point where the whole body of the offending function is empty except for a fake return value
• Clean solution, then rebuild
• Closing all files, then clean, then rebuild, reopening files
• Renaming the function that contains the error
• Lifting the used computation expression into function application syntax (to find out whether the computation expression syntax caused this).
• Forcing another syntax error, then removing this. But it just came back.

Related information

• Windows 7, latest SP's etc
• VS 2017, v15.3.1.0, Preview 1
• Preview version of 18 August 2017
• Possibly high severity, if it stymies me, it will stymie most, I guess ;)

It is the first time I have seen this in the 15.3.1.0, in ealier previews of 15.3.0.0 this seemed to happen more often, but at the time a rebuild was usually enough to fix it. I vaguely remember it was reported and fixed, but perhaps not completely so.

[dsyme]

@abelbraaksma Thanks for the report.

That said, this one looks hard to progress without a repro, especially since #3071 will have addressed a large range of "sticky error" problems.

[abelbraaksma]

@dsyme, if I understand that linked issue correctly, is not yet in 15.3.1.0, so it's possible that the foxes there would fix this one. Though I'll try to find a repro, I know it's invaluable. Or maybe someone chimes in who already reproed it.

[cartermp]

@abelbraaksma Correct that this is not in 15.3.1, but it should be in the nightly releases. It would be great if you could test that.

[abelbraaksma]

@cartermp I'd love to, but I've yet to find out how to do that. So far I only installed the previews. I'll check if there's an install or build instruction somewhere.

[cartermp]

We have instructions here: https://blogs.msdn.microsoft.com/dotnet/2017/03/14/announcing-nightly-releases-for-the-visual-f-tools/

[KevinRansom]

I edited the readme to make this more prominent.

[abelbraaksma]

@KevinRansom, @cartermp, thanks for the pointers, I have now installed the latest nightly! The first that shows is that the documentation bug is still there (other issue, I know, I'll report there).

I can't immediately repro this issue, but that's no surprise as I didn't have clear steps to repro to begin with (I tried similar steps before). I suggest we leave it open for a bit until it either reappears or does not resurface for some time to consider it safe to close.

[cartermp]

Sounds good. I'll tag this appropriately and we can close it once you feel that it's fixed.

[BentTranberg]

I had this issue earlier today. Then VS 15.3.2 knocked on my door, and Nightly 15.4.1.17082201. Not only does this issue seem to be fixed, but there appears to be new fiery life in the Error List. No longer sluggish. Must be #3071, am I right? It's been a long wait. Congratulations F# team, and thanks. (update: Roslyn team too, I remember now) This really will make a difference in my daily work.

[cartermp]

@BentTranberg This is indeed #3071 at work 😄. It's a huge fix in terms of impact.

[dsyme]

Closing until we get a definite repro

[abelbraaksma]

@dsyme: I agree. Having worked with the mentioned nightly for a while now, it hasn't resurfaced, while in the past this or similar scenarios came around at least every other day or so. I'll reopen if it does resurface though.

[BentTranberg]

@dsyme, @cartermp, looks like we're going to have to reopen - or create a new issue. (UPDATE: see #3510.)

The issue is still there, and I have discovered how I can reliably reproduce it in one of my solutions. Sorry I don't have time to finish my investigation and produce a repo today, but I will explain what I have found so far. I suspect that can help others reproduce it easily.

This is what I have: VS 2017, 15.3.2. F# Nightly 15.4.1.17082301. From what I understand, and from what I observe, this should include #3071, and the assumption is that this should have fixed this issue. Let me know if I'm wrong.

The solution is F# only, .NET Framework 4.5.2, and NuGet packages.

I checked out (subversion) fresh from my repo. Then I got this. Notice that it's not just FS0039, but mostly that one.

I cleaned the solution, restarted VS. That didn't help - no errors.
I checked out fresh again, and restarted VS - now it REPRODUCED.
I cleaned the solution, deleted the .vs folder, restarted - no errors.
I cleaned the solution, deleted the .vs folder, noticed there were still files in the obj folders, so deleted bin and obj folders, restarted VS - no errors.

Then I noticed I also had a packages folder, so I deleted that too, and also deleted .vs and bin and obj again. Finally REPRODUCED. And repeating gives the same result.

And now I'm out of time in this round, but to conclude: it looks like there's something left behind in the packages folder, perhaps in combination with one of the other folders mentioned, which stops the issue from surfacing.

Severity: Low. This normally only happens at first build after I check out, so it doesn't bother me.

[BentTranberg]

I opened a new issue, #3510, based on further research and a repro, following the observations in my post immediately above. I still suspect that these two reports are the same issue. However, there doesn't seem to be sufficient information here to determine this.

[BentTranberg]

@abelbraaksma, do you use NuGet libraries? BTW, I've never used Paket, so I don't know if what I found could be related to that too. Is your project for .NET Framework? If so, which version?

[forki]

@BentTranberg what does this have to do with paket?

[BentTranberg]

@forki, NuGet and Paket are similar technologies I believe, and because of that I'm wondering if the problem I found also exists when Paket is used. Since I am not familiar with Paket, perhaps someone else would be interested in checking this out. It might bring us a step closer to finding out what's going on.

Anyway, I'm primarily thinking about this in relation to what I found in #3510, so perhaps I should mention this in a comment there too.

[abelbraaksma]

@abelbraaksma, do you use NuGet libraries? BTW, I've never used Paket, so I don't know if what I found could be related to that too. Is your project for .NET Framework? If so, which version?

@BentTranberg: yes, I use NuGet. Since not all of my projects can rely on Paket, I have never changed to using Paket (shame on me). The project is built for .NET 4.6.2, uses F# 4.0 and is a mix of C# and F# libraries, executables and applications.

But when I wrote the OP I also noticed this behavior with the latest versions of everything.

Recently I have not seen it being as sticky as mentioned in the OP, but it is often extremely slow in removing compile error messages, sometimes up to two minutes (which is odd, given that a full compile of that particular project only takes about 20 seconds).

Note that these timings are with latest nightlies as available today, using VS2017 15.4.0.0 Preview 1, I have not tried with uninstalling back to the latest VS2017 RTM.

@dsyme, @forki, the latest nightlies available through Automatic Update are 15.4.1.17082201, which seems to be August 23. Is this up-to-date? Is there a way I can verify this, i.e., a list of available nightlies, or is what this screen tells me guaranteed the latest?

Finally: I know a lot has happened about sluggishness of VS + F#, but I feel that it is back. I can type faster than F# can print my letters to the screen...., switching tabs takes two or so seconds, going to definition can take up to 15 seconds. This may or may not be related to this issue. But since it's a nightly I am using I think I will let it run its course for now and hope/wait for the next version.

[abelbraaksma]

@dsyme / @forki, I found it, apparently it is here: https://dotnet.myget.org/feed/fsharp/package/vsix/VisualFSharp, so yes, I used the latest that was published there.

(found it through https://blogs.msdn.microsoft.com/dotnet/2017/03/14/announcing-nightly-releases-for-the-visual-f-tools/, maybe not the first place where people look, perhaps a direct link on the home page is helpful? It's where I looked first)

[cartermp]

@abelbraaksma Can you uninstall nightlies on your 15.4 Preview machine? Nightly releases are intended only for the latest stable release. Although I doubt this is significant, it at least reduces one thing from the set of possible reasons why you're seeing sluggish behavior again.

[abelbraaksma]

@cartermp: with "latest stable", do you mean VS2017 RTM, i.e., the "official" release? Because then I can install them back to back on the same machine.

[cartermp]

Yes, latest stable is RTM, or more specifically, 15.3.2.