IOperation Analyzers and Fields

[Hosch250]

Version Used: Latest Release

Steps to Reproduce:

1. Create an analyzer that runs off of IOperation.
2. Try to fire it on fields: OperationKind has field-related items FieldInitializerInCreation, FieldInitializerAtDeclaration, and FieldInitializerInCreation.

Expected Behavior: None of these fire on bool _foo;, which is expected given the names. I'd expect there to be a FieldDeclaration that fires on any FieldDeclarationSyntax node.

Actual Behavior: There is no OperationKind that makes the analyzer run on any field regardless of how it is written.

@CyrusNajmabadi: @jmarolf told me to make an issue for this and ping you.

[sharwell]

@Hosch250 It sounds like what you want is a symbol analyzer, not an operation analyzer. These are easy to write for your described scenario.

[Hosch250]

Oh sure, I know how to write those. I'm a bit confused on what all is what--better break out the search engine again. It's somewhat confusing, though, because there is OperationKind.VariableDeclaration, but no OperationKind.FieldDeclaration. A variable doesn't need to be assigned when it is declared, just like a field...

[CyrusNajmabadi]

@Hosch250 IOperation is currently only a prototype. We're working on actually producing a full, real supported API for it. We'll keep your use case in mind as we go through our list of work items. Tagging @jinujoseph for visibility.

Note that I think is simply 'by design'. your "bool _foo;" is simply a field. A field initializer would be something like "bool _foo = code;" IOperation attempts to give you a rich semantic tree to represent the code that actually executes, not really the symbols that may be initialized from the code that executes.

[Hosch250]

OK, thanks for the explanation. So, I should typically not write an analyzer off a syntax node, but should work with ISymbol and IOperation for analyzing symbols and operations?

[CyrusNajmabadi]

@Hosch250 It really depends on what you're doing. :)

Lots of analyzers are suited to be written as syntax-analyzers. However, the benefit of IOperation over them is twofold:

1. You get all the semantics in the operations, meaning you don't have to go back to the semantic model all the time with the nodes you're analyzing.
2. You get VB+C# support generally for free.

The downside is that you are working on an abstraction. So if there was something particular to a specific language's syntax, then you wouldn't see that directly in the IOperation tree (though you could use teh SyntaxNode each operation exposes to track back to those pieces of syntax).

[Hosch250]

OK, I'll write a few analyzers with it to see how it works better.

[CyrusNajmabadi]

Take a look at https://github.com/dotnet/roslyn/blob/master/src/Features/Core/Portable/PopulateSwitch/PopulateSwitchDiagnosticAnalyzer.cs

It's an example of an analyzer that works for VB and C# without having any VB/C# specific code in it.

[Hosch250]

Yup, I wrote that one originally, and then you rewrote it. That's where I first learned about IOperation, but school and other projects have kind of interfered with my learning it properly.

[CyrusNajmabadi]

d'oh! I forgot about that :)

Note: learning about IOperation is definitely something you can do. But do take into account it's very much in flux. What is checked in now is simply a very rough prototype. And the work to actually produce a real API is going on as we speak.

[jinujoseph]

We're going to close this out currently as being unactionable.