Fsharp: "FSharpDocumentDiagnosticAnalyzer throws TaskCanceledException" warning

[vasily-kirichenko]

[longqinsi]

I encountered the same bug. I'm using VS2017RC -- VS15.0.26014.0.

[cartermp]

@vasily-kirichenko Can you provide a repro for this?

[vasily-kirichenko]

I cannot reproduce it on a newly created project, but it's always reproduced on my older simple solution:

This solution is available here https://github.com/vasily-kirichenko/fsharp-settings-dialog-bug

[cartermp]

@KevinRansom @brettfo we should take a look at this and see if we can get it fixed for RTM.

[amazingant]

I don't have a good repro for it, but I have been seeing a large number of Analyzer 'Microsoft.VisualStudio.FSharp.Editor.SimplifyNameDiagnosticAnalyzer' threw an exception of type 'System.Threading.Tasks.TaskCanceledException' with message 'A task was canceled.'. errors mixed together with the ones relating to FSharpDocumentDiagnosticAnalyzer. Not knowing what's going on, I'm hesitant to say they are definitively related, but they both show up at the same time for me.

[blewater]

Hello,
I'd like to add my info on this issue that I experienced along with issue 2550 on an existing solution that I opened with visual studio 2017.

Errors

I have been getting both 1-or more warnings FSharpDocumentDiagnosticAnalyzer throws TaskCanceledException and abundant SQL type is not defined errors though not consistently. Rarely I also get errors about the compiled project dll. This is a solution that builds fine with vs2015.

Existing Multiproject 2015 Solution opened in RTW 2017

So I reduced my solution to 2 projects. One using sql type provider (FSharp.Data.TypeProviders) and the 2nd project referencing the provider's types (both are dll library .net 4.6.1 projects). And when I continue removing functions beyond a critical point of complexity all the intellisense errors disappear but not the aforementioned warnings necessarily.

Rebuilding it

When I click on Rebuild it almost always concludes to "Rebuild All failed" which upon hitting F6 again it instantly changes to "Build succeeded".

What appears to make a difference in the .sln

The solution initially contained these lines:

# Visual Studio 14
VisualStudioVersion = 14.0.25420.1

When you add (remove too I think) a project it automatically changes those to these:

# Visual Studio 15
VisualStudioVersion = 15.0.26228.4

Just changing the sln content may take the errors or make them appear again within a 1 minute. Does not appear though that the declared version makes the difference.

Packages in the 2 projects

Project 1 (.net 4.6.1)

packages
   package id="FSharp.Core" version="4.1.0" targetFramework="net462"
   package id="FSharp.Data" version="2.3.2" targetFramework="net462"
   package id="FSharp.Data.TypeProviders" version="5.0.0.2" targetFramework="net462" 
   package id="FSharpLint.MSBuild" version="0.4.11" targetFramework="net462" 
   package id="NLog" version="4.4.3" targetFramework="net462" 
   package id="System.ValueTuple" version="4.3.0" targetFramework="net462" 
packages

Project 2 (.net 4.6.1)

packages
   package id="FSharp.Core" version="4.1.0" targetFramework="net462"
   package id="FSharpLint.MSBuild" version="0.4.11" targetFramework="net462"
   package id="NLog" version="4.4.3" targetFramework="net462"
   package id="System.ValueTuple" version="4.3.0" targetFramework="net462"
packages

[cartermp]

@nethatix Thanks for the info. I'll see if I can repro this on my own.

[Kurren123]

I am also experiencing this

[saul]

Digging into this, it looks like ComputeProjectDiagnosticAnalyzerDiagnosticsAsync has a try/catch to see whether the cancellation came from the same cancellation token as the one that was passed into the analyzer. Maybe we're failing that check?

[saul]

Fixed in #2770 (I hope)

[BentTranberg]

I've got VS 2017 15.1 (26403.3) and Visual F# Tools, 15.4.1.17040601. My medium sized F#/C# solution still generates one single warning of this type. There used to be a handful in the last few weeks, but whether it's #2770 doing good, or just a coincidence that the count dropped...

Warning AD0001 Analyzer 'Microsoft.VisualStudio.FSharp.Editor.FSharpDocumentDiagnosticAnalyzer' threw an exception of type 'System.Threading.Tasks.TaskCanceledException' with message 'A task was canceled.'

[cartermp]

Argh this bug is rather evasive

[cartermp]

@BentTranberg is there a way for you to perhaps reduce that to a minimal repro that we could take a look at?

[BentTranberg]

I am unable to reproduce the issue now, and I did not change the solution since my last report four hours ago. My VCS tells me so. Four hours ago I also did a Clean, restarted VS, and did a Rebuild, and the warning was still there. I also tried now going back to a release at the start of the month, and there was no warning of this kind now. I have no clue how this happened, but I think perhaps the issue should just stay closed unless there are more reports, or somebody really wants to pursue it.

Update, theory: The warning appeared in the Error List pane, and everything in there comes from F# IntelliSense, and not the compiler. The Output to Build pane did not show the warning - I checked that. I bet doing a Clean doesn't affect IntelliSense, and that the warning I observed was cached from earlier, before todays update of VS, and what was possibly also todays update of Visual F# Tools, since I don't think I used VS 2017 for some days. What lead me to think of this, is that I believe I have seen similar odd behavior earlier, related to F# - that the Error List contains messages from earlier sessions. Conclusion if you go along with this theory: Don't reopen this issue unless more reports come in.

Update: Suddenly I have two of these warnings again. I guess this is what's termed "Flaky". I'll work on reproducing it with a minimal example.

[cartermp]

Sounds good. Thanks for raising the issue - hopefully it's gone forever 😄

[BentTranberg]

Ahem, boiling that down to a minimal example was not at all easy. The warnings seems to stick when they should go, and vice versa, and restarting VS seems to be the only way to trigger a change, and I am not sure I can even trust that to work. This makes it very time consuming to boil it down. I am thinking this might be caused by issues with the Error List pane (#2548, #2550, +?). Can I suggest then that we wait for improvements to the other issues before I try this again? There was some very interesting progress on #2548 today (thanks, @saul), so I'm hoping the wait will not be long at all before I try again.

[0x53A]

Using this version (which I think is the latest?)

I got this after working with the Paket solution for a while, with a lot of open files and a lot of git diffs open.

Details:

Severity    Code    Description Project File    Line    Suppression State   Detail Description
Warning AD0001  Analyzer 'Microsoft.VisualStudio.FSharp.Editor.UnusedOpensDiagnosticAnalyzer' threw an exception of type 'System.Threading.Tasks.TaskCanceledException' with message 'A task was canceled.'.    Paket.Tests     1   Active  Analyzer 'Microsoft.VisualStudio.FSharp.Editor.UnusedOpensDiagnosticAnalyzer' threw the following exception:
'System.Threading.Tasks.TaskCanceledException: A task was canceled.
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.Diagnostics.EngineV2.DiagnosticIncrementalAnalyzer.Executor.<ComputeDocumentDiagnosticAnalyzerDiagnosticsAsync>d__12.MoveNext()
-----
'.
Warning AD0001  Analyzer 'Microsoft.VisualStudio.FSharp.Editor.UnusedOpensDiagnosticAnalyzer' threw an exception of type 'System.Threading.Tasks.TaskCanceledException' with message 'A task was canceled.'.    Paket.Core      1   Active  Analyzer 'Microsoft.VisualStudio.FSharp.Editor.UnusedOpensDiagnosticAnalyzer' threw the following exception:
'System.Threading.Tasks.TaskCanceledException: A task was canceled.
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.Diagnostics.EngineV2.DiagnosticIncrementalAnalyzer.Executor.<ComputeDocumentDiagnosticAnalyzerDiagnosticsAsync>d__12.MoveNext()
-----
'.
Warning AD0001  Analyzer 'Microsoft.VisualStudio.FSharp.Editor.FSharpDocumentDiagnosticAnalyzer' threw an exception of type 'System.Threading.Tasks.TaskCanceledException' with message 'A task was canceled.'. Paket.Core      1   Active  Analyzer 'Microsoft.VisualStudio.FSharp.Editor.FSharpDocumentDiagnosticAnalyzer' threw the following exception:
'System.Threading.Tasks.TaskCanceledException: A task was canceled.
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.Diagnostics.EngineV2.DiagnosticIncrementalAnalyzer.Executor.<ComputeDocumentDiagnosticAnalyzerDiagnosticsAsync>d__12.MoveNext()
-----
'.
Warning AD0001  Analyzer 'Microsoft.VisualStudio.FSharp.Editor.FSharpDocumentDiagnosticAnalyzer' threw an exception of type 'System.Threading.Tasks.TaskCanceledException' with message 'A task was canceled.'. Paket.Tests     1   Active  Analyzer 'Microsoft.VisualStudio.FSharp.Editor.FSharpDocumentDiagnosticAnalyzer' threw the following exception:
'System.Threading.Tasks.TaskCanceledException: A task was canceled.
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.Diagnostics.EngineV2.DiagnosticIncrementalAnalyzer.Executor.<ComputeDocumentDiagnosticAnalyzerDiagnosticsAsync>d__12.MoveNext()
-----
'.
Warning AD0001  Analyzer 'Microsoft.VisualStudio.FSharp.Editor.UnusedOpensDiagnosticAnalyzer' threw an exception of type 'System.Threading.Tasks.TaskCanceledException' with message 'A task was canceled.'.    Paket.Tests     1   Active  Analyzer 'Microsoft.VisualStudio.FSharp.Editor.UnusedOpensDiagnosticAnalyzer' threw the following exception:
'System.Threading.Tasks.TaskCanceledException: A task was canceled.
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.Diagnostics.EngineV2.DiagnosticIncrementalAnalyzer.Executor.<ComputeDocumentDiagnosticAnalyzerDiagnosticsAsync>d__12.MoveNext()
-----
'.
Warning AD0001  Analyzer 'Microsoft.VisualStudio.FSharp.Editor.FSharpDocumentDiagnosticAnalyzer' threw an exception of type 'System.Threading.Tasks.TaskCanceledException' with message 'A task was canceled.'. Paket.Tests     1   Active  Analyzer 'Microsoft.VisualStudio.FSharp.Editor.FSharpDocumentDiagnosticAnalyzer' threw the following exception:
'System.Threading.Tasks.TaskCanceledException: A task was canceled.
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.CodeAnalysis.Diagnostics.EngineV2.DiagnosticIncrementalAnalyzer.Executor.<ComputeDocumentDiagnosticAnalyzerDiagnosticsAsync>d__12.MoveNext()
-----
'.

[BentTranberg]

with a lot of open files and a lot of git diffs open

That's what triggers it! The more open files, the higher the chance of getting this warning. Perhaps. I opened all the files in the project that the warnings originated from, and voila! Three warnings. It's late now, so I have to continue this tomorrow evening CET at the earliest. But I hope this can help others reproduce it.

[saul]

Hmm there may be a case that I've missed... but I thought I'd caught the root cause and I can't reproduce this with my locally built F# Tools.

[BentTranberg]

Just a thought. Do you use only the Error List pane to detect these exceptions while trying to fix this issue? If so, won't that be a problem, considering the issues reported related to output to the Error List pane? I am thinking the exceptions that produce these warnings perhaps occur all the time in my solution, but I don't see them all the time because of those other issues.

[blewater]

Hello,
With 15.4.1.17040601 the count of warnings has come down to 3 after working with an all F# solution using database and excel type providers.

[saul]

@BentTranberg the analyzer warnings will always appear in the Error List as they're produced by Roslyn, not by F#. I think the warnings now are coming from a nested task that does not have these fixes introduced in my PR. I don't think there's any more work to do here.

[BentTranberg]

Appears completely fixed now. I currently have VisualFSharpTools version 15.4.1.17041802. Thank you very much.

[BentTranberg]

Argh!!!! And again I spoke too soon. I think I'm going to make a rule for myself, saying I need at least a full days intensive work without observing any warning before I make any claims. But I do believe the frequency has come down at least. Pasting the error from the Error List pane:

Warning AD0001 Analyzer 'Microsoft.VisualStudio.FSharp.Editor.FSharpDocumentDiagnosticAnalyzer' threw an exception of type 'System.Threading.Tasks.TaskCanceledException' with message 'A task was canceled.'.

VisualFSharpTools version 15.4.1.17041802. Visual Studio 2017, v 15.1 (26403.7)

UPDATE to this post: The "Tools" column in the Error List pane says the warning is from "FSharp.Editor", while the errors in F# source is from "FSharp.Editor [Visual F# Tools]".
UPDATE2: The F# errors went away immediately when I removed the error in the source, but the warning stuck. I tried closing the editor pane, but then there were immediately two of these warnings instead of just one.

[cartermp]

@BentTranberg Could you try @saul's PR #2877 to see if you can still repro on it? That is if you're willing to clone + download the dependencies. Specifically, you'll need:

1. F# and .NET (which you have)
2. Visual Studio Extensibility workload
3. Windows 10 SDK (you could install the UWP workload or find it in the Individual Components tab)

Then, open the Visual Studio Developer Command line in admin mode, and run build.cmd vs. This will build the tools and other stuff. I usually follow that with msbuild VisualFSharp.sln. Then, you can set VisualFSharpOpenSource project as the startup project. When you f5, it will launch a debug hive of VS with the changes to the tools.

Not the quickest or easiest way to verify, but it would help to have more eyes on @saul's work if you have the time and patience! 😄

[BentTranberg]

@cartermp, I have been thinking lately that I should somehow get involved with the source and start debugging on my own so that I can give more intelligent feedback, so your post is perfectly timed from my point of view. I hope to get a chance this week to try your instructions.

[cartermp]

Great! Feel free to reach out for any questions.

[BentTranberg]

Other issues seems to have been fixed or improved now, and so today it was easy to try to produce a minimal solution with these warnings. I succeeded, sort of, but then again not. What I discovered during the hour I spent on reducing the solution, is that these warnings come and go as they please all over the place in F# projects. They are not tied to any specific source. They seem to occur more frequently in projects with a large number of F# source files, which means that they are far less likely to occur in the minimal solution I am posting now, but I assure you they were reproduced repeatedly but far from consistently with these exact files on my machine. They seem to occur frequently when I open F# source files through the Solution Explorer, but also when I do other things, not sure exactly what, with the F# editor in VS. While working on reducing the solution, it was bothersome that these warnings, and also other errors and warnings, would stick in the Error List pane. I got rid of them instantly by closing and reopening the solution. Btw, I also installed VS 2017 on a second machine today, opened the solution in question, and this issue is also present on that machine.

TDNet.zip

[BentTranberg]

While reading my previous post, I found that the solution was staring me in the face. (Not sure whether pun was intended.) I simply added a whole bunch of bogus source files to the F# project, and now it's rather easy to reproduce the warnings. New solution attached.

TDNet2.zip

To provoke the warnings, try opening a lot of files, do Rebuilds, create some error, compile, and remove the error, compile, open more files, compile, and just keep on messing around with this for a while. Judging from the behavior on my machine, you will get the warnings within a minute or three.

[BentTranberg]

I have upped the count of bogus files to 100. Open the solution, open 10 bogus files, compile, open 10 bogus files, compile, etc. In this way, I am now able to reproduce the warning in less than 10 seconds, repeatedly. (By "open" I mean double click the file in SE. And "compile" means do a Rebuild.)
TDNet3.zip

[cloudRoutine]

I still get them all the time too

And i'm using a build of VFT that includes @saul 's task cancellation fixes

[blewater]

Same here with latest visual tools 15.4.1.17042001

[saul]

@BentTranberg thanks for the repro - judging by @cloudRoutine's post it looks like there's still work to do.

[dsyme]

I've been encountering this while doing some other work on bug fixing. I'm trying to understand a few things to help me get a better mental model as to why we have this problem

1. Is it actually a problem for a diagnostic analyzer to throw TaskCanceledException? Can we just catch those exceptions and not report them to Roslyn?
2. Are the exceptions being thrown when the task is really cancelled, or are they being thrown for work that should be proceeding?
3. What's the nature of the fix here?
4. Do we know if this problem could cascade to more serious problems?

[saul]

Is it actually a problem for a diagnostic analyzer to throw TaskCanceledException? Can we just catch those exceptions and not report them to Roslyn?

No - we're being cancelled by Roslyn and bubbling up the TaskCanceledException. As somewhere in FSharp.Core/VFT we're not throwing TaskCanceledException correctly (i.e. with the incorrect cancellation token), Roslyn thinks that something else cancelled the task. Therefore it reports the error.

Are the exceptions being thrown when the task is really cancelled, or are they being thrown for work that should be proceeding?

As above.

What's the nature of the fix here?

Fix how we raise TaskCanceledException in FSharp.Core/wherever else we raise it (or OperationCanceledException).

Do we know if this problem could cascade to more serious problems?

No, it shouldn't. It's just annoying.

[dsyme]

@saul Thanks, I see. Can we just catch TCE from StartAsTask and rethrow one with the right cancellation token?

[saul]

Yes absolutely, but it'd be a band-aid over the bug. We're throwing TCE wrong somewhere... it's just finding out where. I think the cancellation tokens aren't being threaded through correctly, it may be worth poring over my PRs again to see if there's something I missed/changed wrong.

[dsyme]

@Saul It's probably uses of AwaitTask, which use this:

                    else args.aux.econt (ExceptionDispatchInfo.Capture(new TaskCanceledException(completedTask)))

You can't specify a cancellation token when creating the TaskCanceledException

[saul]

@dsyme yes but if you look at the code for TaskCanceledException, it passes completedTask's cancellation token to the OperationCanceledException constructor.

[dsyme]

@saul Ah, yes, but for code like this:

                                let! sourceText = context.Document.GetTextAsync() |> Async.AwaitTask

we're not passing the ambient cancellation token into GetTextAsync (which has an optional argument for a cancellation token). Don't you love the bugs caused by the C# async approach to explicitly passing cancellation tokens?

[dsyme]

Some others like this don't allow you to pass in a cancellation token at all, I suppose they can't be cancelled -

        settingsManager.SetValueAsync(storageKey typeof<'t>, JsonConvert.SerializeObject settings, false)
        |> Async.AwaitTask 

            do! context.OnDefinitionFoundAsync(definitionItem) |> Async.AwaitTask |> liftAsync

                                do! context.OnReferenceFoundAsync(referenceItem) |> Async.AwaitTask |> liftAsync

[saul]

Urgh 😞 maybe we are best just catching all TaskCanceledException and throwing the correct exception instead then for the analyzers?

[dsyme]

I wonder what happens if you don't pass that cancellation token in - does it just become uncancellable, or does it use a new one to throw on? I suppose the latter.

Anyway I'll dig out the problematic cases for now, it's best to pass in the right cancellation token in any case. But a catch-all would also make sense.

I also thought about adding this args.aux.token.IsCancelled || in control.fs.

                        if args.aux.token.IsCancelled || useCcontForTaskCancellation

in

        let continueWith (task : Task<'T>, args, useCcontForTaskCancellation) = 

            let continuation (completedTask : Task<_>) : unit =
                args.aux.trampolineHolder.Protect((fun () ->
                    if completedTask.IsCanceled then
                        if args.aux.token.IsCancelled || useCcontForTaskCancellation
                        then args.aux.ccont (new OperationCanceledException(args.aux.token))
                        else args.aux.econt (ExceptionDispatchInfo.Capture(new TaskCanceledException(completedTask)))
                    elif completedTask.IsFaulted then
                        args.aux.econt (MayLoseStackTrace(completedTask.Exception))
                    else
                        args.cont completedTask.Result)) |> unfake

            task.ContinueWith(Action<Task<'T>>(continuation), continueWithExtra args.aux.token) |> ignore |> fake

[dsyme]

@Saul There are also cases like this where Async.Parallel is involved - should we be passing in the outer CancellationToken, or the "linked" cancellation token for the particular partition of Async,Parallel? In theory the latter to emulate F#'s implicit propgation of cancellation tokens - but you said that they do exact comparison of the cancellation tokens? Independent of linking?

                    |> Seq.map (fun documentId ->
                        async {
                            let doc = solution.GetDocument(documentId)
                            let! sourceText = doc.GetTextAsync(cancellationToken) |> Async.AwaitTask
                            match RoslynHelpers.TryFSharpRangeToTextSpan(sourceText, range) with
                            | Some span ->
                                let span = Tokenizer.fixupSpan(sourceText, span)
                                return Some (DocumentSpan(doc, span))
                            | None -> return None
                        })
                    |> Async.Parallel

[dsyme]

In fact those Async.Parallel could easily be the cause of all the problems - not just for the individual tasks, but for cancellation points implied by the F# control structure.

OK, this has convinced me that we should convert the OCE's as they come out. I don't trust that Roslyn equality check as meaning anything valuable in the presence of linked tokens, we can just do what we need to do to make it go away

[dsyme]

Fixed

[kdurkin77]

I'm on version 15.2 (26430.14) and i still see these warnings :/

Warning AD0001 Analyzer 'Microsoft.VisualStudio.FSharp.Editor.FSharpDocumentDiagnosticAnalyzer' threw an exception of type 'System.Threading.Tasks.TaskCanceledException' with message 'A task was canceled.'.

[dsyme]

@kmiller77 Yes, the fix will be in 15.3

[kdurkin77]

Excellent, thank you!!!!

[ImaginaryDevelopment]

any eta? or link to the vs update that will encapsulate it?

On Thu, Jun 22, 2017 at 3:48 PM, kmiller77 [e-mail] wrote:

Excellent, thank you!!!!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/issues/2100#issuecomment-310483447,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHZvMjc9XVlIAaJRus0ZXoQ6RMYCS1_ks5sGsUBgaJpZM4LVXj3
.

[dsyme]

@ImaginaryDevelopment You can either

• switch to the nightly https://blogs.msdn.microsoft.com/dotnet/2017/03/14/announcing-nightly-releases-for-the-visual-f-tools/
• build master
• wait for Visual Studio 2017 Update 3 (= version "15.3")

[BentTranberg]

@dsyme, I am a bit confused following your last comment. I have VS 2017 Pro 15.2 (26430.14), and Visual F# Nightly 15.4.1.17062301. I still see the warnings, and my understanding from the conversations I have been following was that this was expected until I get Update 3. But if you did not expect me to see the warnings at my current setup, please let me know so I can start work on creating a new repro. The TDNet3.zip that I posted above, no longer produces errors on my machines.

[dsyme]

Visual F# Nightly 15.4.1.17062301. I still see the warnings

Hmmmm... I am no longer seeing these warnings (unless I've been blanking them out without thinking about it). If you have a simple repro please send it along (open a new issue or add it here)

[saul]

@dsyme for what it's worth I've been on the nightlies for weeks now and haven't seen a single one (this is on a 400 project solution, and I was seeing them tons before).

[BentTranberg]

This is a reasonably small repro. I suspect it takes a certain amount of source, so I haven't tried to minimize it. I actually had to add some nonsense back, or else there wasn't enough to provoke the warnings. Never mind what the source looks like. I used a machete on it.

I haven't found a way to reproduce the warnings consistently at this time. (See my previous post above for version information.) Try to compile, open files, edit some here and there, but don't leave compile errors. I am able to provoke warnings typically within a minute, sometimes a few minutes.

Along with the warnings I also provoke errors that won't go away sometimes. These are errors that are legitimate at some point while editing, but should go away when editing is done. When warnings and possibly errors stick, I close the solution, and reopen it, for a new attempt at provoking this.

Repro:
Repro4.zip

[BentTranberg]

I compiled Repro4.zip on another freshly installed machine with a fresh VS 2017, and got these warnings.

I haven't seen these before. I should have. Right now the only explanation I can think of, is that these are warnings that should have been reported instead of the warnings we are struggling with. Is that a possibility?

Anyway, the warnings in question - ... Analyzer throws... - was also provoked on that fresh installation. So I believe even more this last repro can be of help.

PS: I got confusing errors in the Error List when building again. Remember to check the Output pane to see whether build actually succeeded or not.

[BentTranberg]

Within the last week or maybe two, the last remnants of this issue seems finally to have disappeared completely when editing my solution. The Repro4.zip posted no longer triggers anything. Just for the record, currently at VS 2017, v 15.2 (26430.14, and .15 just now came in so I tested that too) and F# Nightly 15.4.1.17070701.

[cartermp]

@BentTranberg that's great to hear!

[dsyme]

Glory hallelujah praise be shouted from the hilltops

[BentTranberg]

Ghostbusters and Gremlins both had sequels ...