Show analysis context for AD0001

[sharwell]

When an analyzer throws an exception within a SyntaxNodeAnalysisContext, it would be very helpful if the message details included information about the type of syntax node which was being analyzed at the time as well as its location within the source file. In fact, the span of the node could actually be used as the span for the AD0001 diagnostic itself.

This applies in various degrees to several analysis context objects which analyzers can listen to. Each of these contexts should be handled in the most meaningful way available for that context.

📝 This is related to but not a duplicate of #6696.

[heejaechang]

I will merge these two issue to one and address them in one PR - #6696

[heejaechang]

see #7917 for more information.

basically added a way to crash process on analyzer exception using regkey.

[sharwell]

@heejaechang Before going in that direction, I want to clarify the request.

For a syntax tree action, you might see this:

An analyzer exception occurred in {analyzerName} while analyzing {sourceFile}.

For a syntax node action, you might see this:

An analyzer exception occurred in {analyzerName} while analyzing {syntaxKind} node at {fileLinePositionSpan}.

For a symbol action, you might see this:

An analyzer exception occurred in {analyzerName} while analyzing {symbolName}.

[heejaechang]

@sharwell you can ask them to give you dump instead. that information might have let you fix a bug before, but next bug you might need yet another information to actually figure that out.

[sharwell]

I'm sure we've had a couple exceptions, but having been intricately involved in the development and testing of over 150 production analyzers that the information requested here represents the complete set of information typically required to address a problem. With less information we have trouble creating test cases (e.g. DotNetAnalyzers/StyleCopAnalyzers#1534), and rarely if ever have we needed additional information.

I believe the request as written is reasonable (straightforward to implement and easy for users to work with) and precisely describes the overwhelming majority scenario that analyzer authors will encounter over time. I do not believe that the alternative described is a suitable replacement. In addition to obvious usability issues (we don't want to tell users to modify their registry and crash their IDE), we still have to address multiple other concerns:

1. What security and privacy issues are involved in the dump? Presumably the dump will either contain proprietary information, or it will be missing the context necessary to reproduce the problem, which is exactly what we're trying to avoid.
2. How are crash dumps transmitted and stored?
3. Most developers will not know without further training how to derive a test scenario from crash dumps.
4. For one-off or transient issues like the one mentioned above, users may only observe the problem one time, and will be unable to use the crash dump approach to provide usable information.

I really think this issue should be reopened for additional discussion regarding directly implementing the described feedback.

[heejaechang]

@sharwell I am fine re-opening this for further discussion, but I really don't think adding bunch of information here can be generalized. as the original bug report described, information author would want will be toward whatever analyzer they are developing and things needed for it.

...

by the way, if you really want this, you can do it yourself already, catch exception in your registered action, and throw exception with original exception as inner exception with all information you want to capture, description pane will display all those information.

...
about your question.

1. if you really care about privacy, then we can't show sourcefile or symbolname as well since those are considered private information as well. also, information you described above doesnt contain any information you won't get from dump.
2. this is up to between user and author.
3. I assume you are talking about diagnostic analyzer author? I am not sure how they can derive test case from the description as well. are you assuming they actually have access to the source file at the first place? and that is why it is assumed that sourcefile, location and symbol name is enough to create test case?
4. I think this actually give it higher chance to fix that one-off issue since user can keep working as they would normally do and when encounter the issue, it actually save the dump.

[heejaechang]

I re-opened the issue to further discuss this issue as @sharwell requested.

[heejaechang]

@mavasani @srivatsn @JohnHamby

so, @sharwell want to add more context related information to error list description pane. and I made it easy for users to create a dump when exception is thrown from user analyzer.

and question is whether dump is enough or we should still add more info to the description pane.

[srivatsn]

Not every user is going to have the time or willingness to set a reg key and capture a dump. For the users who are willing to do that, great, we should have that feature because that captures the maximum amount of information. However, some users might just run into a warning and report that with the text and then not follow up. For those cases, having more information that makes the error diagnosable would be useful. There's ofcourse diminishing returns to adding more and more information there but the information requested in this issue seems reasonable to me and doesn't sound like would make our code more complex.

[Vannevelj]

I echo @sharwell his request for more information in the actual error pane message. Reconstructing test scenarios often involves stepping through context.Node.Parent.Parent.Parent.etc until I see enough information to reconstruct a test scenario. Knowing what file caused it and on which line would give me a lot of contextual clues to figure out what might have caused it.

[heejaechang]

@Vannevelj that means you stepping through repro step using debugger, which require you to first construct repro step and then debug it through yourself.

dump will let you straight to the problem without going through hassle of figuring out repro step first which might or might not possible or straightforward.

[heejaechang]

@sharwell does this look okay?

Analyzer 'Microsoft.CodeAnalysis.CSharp.InvokeDelegateWithConditionalAccess.InvokeDelegateWithConditionalAccessAnalyzer' threw the following exception:
'Exception occurred with following context:
Compilation: ConsoleApplication3
SyntaxTree: C:\Users\hechang\documents\visual studio 2015\Projects\ConsoleApplication3\ConsoleApplication3\Program.cs
SyntaxNode: "if (true) { Console.WriteLine( ..." IfStatementSyntax@[247..287)

System.Exception: test
at Microsoft.CodeAnalysis.CSharp.InvokeDelegateWithConditionalAccess.InvokeDelegateWithConditionalAccessAnalyzer.SyntaxNodeAction(SyntaxNodeAnalysisContext syntaxContext)
at Microsoft.CodeAnalysis.Diagnostics.AnalyzerExecutor.<>c__DisplayClass41_1`1.b__1()

at Microsoft.CodeAnalysis.Diagnostics.AnalyzerExecutor.ExecuteAndCatchIfThrows_NoLock(DiagnosticAnalyzer analyzer, Action analyze, Nullable`1 info)

'.

[sharwell]

@heejaechang Oh, that looks very nice. 😄 If we changed one thing, it would be the [247..287) (which is SyntaxNode.Span). The IDE doesn't present absolute positions anywhere, so for a user that has multiple statements in their file starting with if (true) { Console.WriteLine(, it could be difficult to narrow down the location of the node. The LinePositionSpan (I assume from passing the Span to SyntaxTree.GetLineSpan) would give numbers that translate well to the IDE experience.

[heejaechang]

@sharwell done