Make RegisterSymbolAction work on Parameters #13931

dpoeschl · 2016-09-20T17:46:44Z

This is just a proposal to get feedback on the approach of registering more operation or symbol actions when a symbol action is registered with SymbolKind.Local or SymbolKind.Parameter. It also includes some hacks to SymbolAnalysisContext and OperationAnalysisContext to make _isSupportedDiagnostic accessible.

Additionally, we'd need to add tests (somewhere?).

dpoeschl · 2016-09-20T17:47:41Z

@JohnHamby @heejaechang @mavasani @srivatsn @CyrusNajmabadi

CyrusNajmabadi

Cute. I like this approach. It has hte benefit that it makes the API complete, but can also be potentially implemented more efficiently if hte analysis guys want to fill in this gap in another manner.

CyrusNajmabadi · 2016-09-20T17:49:18Z

src/Compilers/Core/Portable/DiagnosticAnalyzer/DiagnosticStartAnalysisScope.cs

@@ -608,6 +608,56 @@ public void RegisterSymbolAction(DiagnosticAnalyzer analyzer, Action<SymbolAnaly
            SymbolAnalyzerAction analyzerAction = new SymbolAnalyzerAction(action, symbolKinds, analyzer);
            this.GetOrCreateAnalyzerActions(analyzer).AddSymbolAction(analyzerAction);
            _symbolActions = _symbolActions.Add(analyzerAction);
+
+            if (symbolKinds.Contains(SymbolKind.Local))


Comment explaining the overall idea here (and below).

msJohnHamby · 2016-09-20T22:18:36Z

This is a very literal interpretation of an idea we discussed last week. The weird thing is that it might actually work.

dpoeschl · 2016-09-21T17:18:40Z

retest windows_debug_unit64_prtest please

Failure: http://dotnet-ci.cloudapp.net/job/dotnet_roslyn/job/master/job/windows_debug_unit64_prtest/3812/testReport/junit/Microsoft.CodeAnalysis.Editor.UnitTests.SolutionCrawler/WorkCoordinatorTests/RegisterService/

Will file a bug if it turns out to not be my fault.

dpoeschl · 2016-09-21T17:23:06Z

src/Test/Utilities/Shared/Diagnostics/TrackingDiagnosticAnalyzer.cs

-            var expectedSymbolKinds = new[] { SymbolKind.Event, SymbolKind.Field, SymbolKind.Method, SymbolKind.NamedType, SymbolKind.Namespace, SymbolKind.Property };
+            var expectedSymbolKinds = new[] 
+            {
+                SymbolKind.Event, SymbolKind.Field, SymbolKind.Local, SymbolKind.Method, SymbolKind.NamedType, SymbolKind.Namespace, SymbolKind.Parameter, SymbolKind.Property


Is this enough test coverage or do I need more specific tests? I don't know how the testing works in this area.

This was not enough. See added unit tests elsewhere.

dpoeschl · 2016-09-21T20:53:33Z

Removed the [Proposal] tag. Let's talk about actually doing this. Can someone point me at places to add tests, if fixing the broken one isn't sufficient and the infrastructure exists?

@JohnHamby @heejaechang @mavasani @srivatsn @CyrusNajmabadi @dotnet/roslyn-analysis @dotnet/roslyn-ide

rchande · 2016-09-21T20:59:27Z

test closed-perf please

rchande · 2016-09-21T21:00:22Z

test closed-perf please

mavasani · 2016-09-21T20:58:06Z

src/Compilers/Core/Portable/DiagnosticAnalyzer/DiagnosticStartAnalysisScope.cs

+
+            if (symbolKinds.Contains(SymbolKind.Parameter))
+            {
+                RegisterSymbolAction(


Registering a symbol action will have no effect until the analyzer driver actually invokes the action on each parameter. Given that analyzer driver is completely driven by symbol declared events from compilation event queue, and we don't generate compilation events for parameters, these will never be invoked.

Right approach would be to avoid registering a separate action here, and instead just iterate over all parameters of the symbol here and invoke symbol actions for parameters.

I think we can file a bug on optimizing these internal implementation details. Thanks to David's good testing, it should be possible to update things internally without worrying about regressions.

mavasani · 2016-09-21T21:02:43Z

src/Compilers/Core/Portable/DiagnosticAnalyzer/DiagnosticStartAnalysisScope.cs

+
+            if (symbolKinds.Contains(SymbolKind.Local))
+            {
+                RegisterOperationAction(analyzer, opContext =>


How is this preferable over actually asking the analyzer authors to register these operation actions? I am hesitant on ourselves registering new actions, as this will also skew up telemetry (for example, how many operation actions were registered).

If we do want to support local symbol kinds, then the correct approach might be to just enhance this method, which executes all operation actions, to account for registered local symbol actions, identify the set of locals for defined operations and then just directly execute symbol actions for these local symbols.

How is this preferable over actually asking the analyzer authors to register these operation actions?

We do not allow analzyers to register operation actions.

The mapping between SymbolKind and the appropriate analyzer operations is not something that may be clear to authors. Look at the example of SymbolKind.Parameter. Getting called back for parameters means enumerating a whole host of cases. The onus should not be on all authors to figure out how to do this properly. It's just something that will lead to excess fragile code to maintain.

It seems pretty clear to me. We have RegisterSymbolAction. We should do what we can to make sure that that works properly for all the possible SymbolKinds that can be passed in.

mavasani

I am hesitant on putting a workaround of registering additional wrapper actions to invoke user registered actions. I don't think there is too much extra work in just invoking the local/parameter actions at the right points in the analyzer driver code itself.

CyrusNajmabadi · 2016-09-21T21:26:04Z

@mavasani It seems like that's an implementation detail optimization that could be done in the future. I think one of hte problems we have is that currently the API isn't working properly and that's impacting consumers. THis is a simple way of getting it working with low risk and low cost. If someone is willing to sign up to do the 'right' fix deep in the analysis engine, that would work. However, that will likely be much more expensive for some people to implement cough me cough since we're not deeply comfortable with all the complexity deep in the engine.

mavasani · 2016-09-21T21:38:55Z

@CyrusNajmabadi

Implementing the parameter callbacks functionality at the right place is trivial - I was basically recommending doing the same thing that @dpoeschl is doing right now, but just at a different place, and this will avoid registering wrapper actions.

Implementing the local callbacks, which we are doing via registering operation actions seems very superfluous to me. The actual work we are doing is just a single call to register a wrapper operation action with OperationKind.VariableDeclaration - I am not sure if there is any real benefit we are providing to analyzer authors here.

CyrusNajmabadi · 2016-09-21T21:42:14Z

I'll let david add more info, but from what i understand, we've actually tried doing the invocation there and it was quite difficult to get right. The problem was especially around:

if (ShouldExecuteAction(analyzerStateOpt, symbolAction))  // line 350

The system seemed to fight reporting additional symbols when we tries to update the code here.

That's why i recommend doing the simple thing here that works. Then, later on, the optimization can be done by people who can really manipulate things efficiently at these depths.

mavasani · 2016-09-21T21:54:27Z

Okay, if we can ensure that things work fine with the wrapper action approach, then I am fine with us opening a tracking item to clean this up and take the current approach.

@dpoeschl - For the unit tests, look at references of CommonDiagnosticAnalyzers - you can define analyzers in that type and then use them in tests in various projects (command line, IDE driver, etc.)

CyrusNajmabadi · 2016-09-21T21:55:04Z

The actual work we are doing is just a single call to register a wrapper operation action with OperationKind.VariableDeclaration - I am not sure if there is any real benefit we are providing to analyzer authors here.

I think we're providing a lot of value. First, analyzer authors can't register this action to begin with. Second, our API right now is incomplete. We state that you can get callback hooks for symbols and yet two very important symbols (locals and parameters) you cannot actually get called back on.

You can hack around that for parameters (but it's ugly, and requires you to understand the rest of our symbolic system). But there's no way to get around this for local variables.

We have provided an incomplete public API. The high order bit is to make it complete and correct. Right now this seems like the cheapest way to do that. If someone can sign up to do it "better" we're happy to defer on that. But if that can't be provided, then this is a better state to be in until that work can happen at some point in the future.

msJohnHamby · 2016-09-21T22:02:13Z

This change fills an important hole in the API. So long as it is functionally correct and can later be replaced by putting the capabilities in the engine, it's a strictly positive step.

mavasani · 2016-09-21T22:02:20Z

We have provided an incomplete public API

Yes, it was unsupported (with a scope of expansion in future) - and in fact we also have an analyzer in MS.CA.Analyzers that flags registering a symbol action with local/parameter (see here). @dpoeschl Can you also open an issue in roslyn-analyzers to add new supported symbol kinds to that analyzer?

rchande · 2016-09-21T22:36:46Z

test perf-closed please

dpoeschl · 2016-09-25T20:56:14Z

@mavasani - Added tests and support for delegate invoke methods (in C# only, see #14062 for the VB problem). Let me know if there's more I should be testing.

I was starting to go down the road of getting parameters of everything, including lambdas, anonymous methods, and local functions. However, these types of methods aren't even reported when you RegisterSymbolAction for SymbolKind.Method, so I've chosen to stay consistent and only report parameters of member-level symbols.

However, I believe this gap should be fixed, especially for local functions. One proposal for how to do this is offered in #14061

dpoeschl · 2016-09-25T20:57:15Z

Also an FYI to @CyrusNajmabadi about #14061 since it caused me to differ my approach here from what we had talked about offline. Let me know how disturbed you are by the change in course.

CyrusNajmabadi

I personally think this is an acceptable approach here. I think there is room for optimization. But as this is all internal, that can come at a later point. The core issue is to get the API working properly as soon as possible so that consumers can depend on it.

CyrusNajmabadi · 2016-09-25T23:37:55Z

src/Compilers/Core/Portable/DiagnosticAnalyzer/DiagnosticStartAnalysisScope.cs

+
+            if (symbolKinds.Contains(SymbolKind.Local))
+            {
+                RegisterOperationAction(analyzer, opContext =>


How is this preferable over actually asking the analyzer authors to register these operation actions?

We do not allow analzyers to register operation actions.

The mapping between SymbolKind and the appropriate analyzer operations is not something that may be clear to authors. Look at the example of SymbolKind.Parameter. Getting called back for parameters means enumerating a whole host of cases. The onus should not be on all authors to figure out how to do this properly. It's just something that will lead to excess fragile code to maintain.

It seems pretty clear to me. We have RegisterSymbolAction. We should do what we can to make sure that that works properly for all the possible SymbolKinds that can be passed in.

CyrusNajmabadi · 2016-09-25T23:39:28Z

src/Compilers/Core/Portable/DiagnosticAnalyzer/DiagnosticStartAnalysisScope.cs

+
+            if (symbolKinds.Contains(SymbolKind.Parameter))
+            {
+                RegisterSymbolAction(


I think we can file a bug on optimizing these internal implementation details. Thanks to David's good testing, it should be possible to update things internally without worrying about regressions.

CyrusNajmabadi · 2016-09-25T23:41:04Z

src/Compilers/Core/Portable/DiagnosticAnalyzer/DiagnosticStartAnalysisScope.cs

+                                throw new ArgumentException(nameof(context));
+                        }
+
+                        foreach (var parameter in parameters.Where(p => !p.IsImplicitlyDeclared))


Note: it would not be clean, but symbols do expose .Language. That means you can handle the VB implicit parameter issue here by doing a language check. As this API is purely for C#/VB, i think it's fine for you to do that.

Filed #14062 to deal with the VB problem someday.

CyrusNajmabadi · 2016-09-25T23:41:37Z

src/Compilers/Core/Portable/DiagnosticAnalyzer/DiagnosticStartAnalysisScope.cs

+                                throw new ArgumentException(nameof(context));
+                        }
+
+                        foreach (var parameter in parameters.Where(p => !p.IsImplicitlyDeclared))


We're going to hit a lot of parameters. might be good to avoid the .Where allocation. YOu can just have an 'if' statement in the foreach body.

CyrusNajmabadi · 2016-09-25T23:42:06Z

src/Test/Utilities/Desktop/CommonDiagnosticAnalyzers.cs

+
+            public override ImmutableArray<DiagnosticDescriptor> SupportedDiagnostics
+            {
+                get


dpoeschl · 2016-10-04T20:14:52Z

Aside from @CyrusNajmabadi's comments, what else do I need to do to earn a signoff? @mavasani @JohnHamby

mavasani · 2016-10-04T20:53:06Z

@dpoeschl Can you file an issue on Area-Analyzers path for refactoring this code to optimize this further and move the callbacks into the core analyzer driver?

mavasani · 2016-10-04T20:54:42Z

@dpoeschl Can you also file an issue on roslyn-analyzers to change RegisterActionAnalyzer to not flag symbol registration of parameters and locals?

msJohnHamby · 2016-10-04T21:20:44Z

Signoff authority rests with @srivatsn . My opinion is that the API enhancement is good. The implementation strategy is slightly unsettling, but it may actually be correct and if so should be serviceable until someone has time to implement the API at a lower level. Is the testing sufficient?

Fixes dotnet#8753

dpoeschl · 2016-10-05T00:15:15Z

Responded to @CyrusNajmabadi 's feedback, and I'll file the follow-up bugs when this gets merged.

dpoeschl · 2016-10-10T22:29:47Z

Removed the functionality for Locals (as a separate commit so that code from the first commit can possibly be reused some day) based on a meeting where we discussed #14061 in more depth.

dpoeschl · 2016-10-18T22:39:44Z

Tagging @ManishJayaswal & @MattGertz for RC Ask Mode approval

dpoeschl added Area-IDE Area-Analyzers labels Sep 20, 2016

dnfclas added the cla-already-signed label Sep 20, 2016

dpoeschl changed the title ~~Make RegisterSymbolAction work on Locals & Parameters~~ [Proposal] Make RegisterSymbolAction work on Locals & Parameters Sep 20, 2016

CyrusNajmabadi reviewed Sep 20, 2016

View reviewed changes

dpoeschl commented Sep 21, 2016

View reviewed changes

dpoeschl force-pushed the RegisterSymbolActionForLocals branch 2 times, most recently from d72fad6 to e7cc951 Compare September 21, 2016 20:22

dpoeschl changed the title ~~[Proposal] Make RegisterSymbolAction work on Locals & Parameters~~ Make RegisterSymbolAction work on Locals & Parameters Sep 21, 2016

mavasani reviewed Sep 21, 2016

View reviewed changes

mavasani suggested changes Sep 21, 2016

View reviewed changes

This was referenced Sep 25, 2016

[Proposal] Provide a way for RegisterSymbolAction to include symbols in member bodies #14061

Open

[Question] Why do C# & VB differ on whether the parameters of a DelegateInvokeMethod are IsImplicitlyDeclared #14062

Open

dpoeschl force-pushed the RegisterSymbolActionForLocals branch from e7cc951 to 6de08f7 Compare September 25, 2016 20:52

CyrusNajmabadi approved these changes Sep 25, 2016

View reviewed changes

mavasani approved these changes Oct 4, 2016

View reviewed changes

Make RegisterSymbolAction work on Locals & Parameters

5a0f453

Fixes dotnet#8753

dpoeschl force-pushed the RegisterSymbolActionForLocals branch from 6de08f7 to 5a0f453 Compare October 5, 2016 00:14

srivatsn approved these changes Oct 6, 2016

View reviewed changes

Remove work for SymbolKind.Local based on offline discussions

54d9890

dpoeschl changed the base branch from master to dev15-rc October 18, 2016 22:38

ManishJayaswal added the Approved to merge label Oct 18, 2016

dpoeschl changed the title ~~Make RegisterSymbolAction work on Locals & Parameters~~ Make RegisterSymbolAction work on Parameters Oct 18, 2016

dpoeschl merged commit cf49294 into dotnet:dev15-rc Oct 18, 2016

bkoelman mentioned this pull request Jan 3, 2017

RegisterSymbolAction with SymbolKind.Parameter is incorrectly reported as unsupported #16214

Closed

dpoeschl mentioned this pull request Jan 9, 2017

Run Naming Rules on parameters #16317

Merged

Make RegisterSymbolAction work on Parameters #13931

Make RegisterSymbolAction work on Parameters #13931

Conversation

dpoeschl commented Sep 20, 2016

dpoeschl commented Sep 20, 2016

CyrusNajmabadi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

msJohnHamby commented Sep 20, 2016

dpoeschl commented Sep 21, 2016

Choose a reason for hiding this comment

dpoeschl Sep 26, 2016 • edited Loading

Choose a reason for hiding this comment

dpoeschl commented Sep 21, 2016

rchande commented Sep 21, 2016

rchande commented Sep 21, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mavasani Sep 21, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mavasani left a comment

Choose a reason for hiding this comment

CyrusNajmabadi commented Sep 21, 2016

mavasani commented Sep 21, 2016

CyrusNajmabadi commented Sep 21, 2016 • edited by dpoeschl Loading

mavasani commented Sep 21, 2016

CyrusNajmabadi commented Sep 21, 2016

msJohnHamby commented Sep 21, 2016

mavasani commented Sep 21, 2016

rchande commented Sep 21, 2016

dpoeschl commented Sep 25, 2016

dpoeschl commented Sep 25, 2016

CyrusNajmabadi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dpoeschl commented Oct 4, 2016

mavasani commented Oct 4, 2016

mavasani commented Oct 4, 2016

msJohnHamby commented Oct 4, 2016

dpoeschl commented Oct 5, 2016

dpoeschl commented Oct 10, 2016

dpoeschl commented Oct 18, 2016

dpoeschl Sep 26, 2016 •

edited

Loading

mavasani Sep 21, 2016 •

edited

Loading

CyrusNajmabadi commented Sep 21, 2016 •

edited by dpoeschl

Loading