Expose API similar to AnalysisContext within the Workspace API about roslyn

[jasonmalinowski]

Can you clarify what type of feature you're looking to write? It's helpful to have motivation so we can ensure we actually meet your (imagined) needs.

[mattwar]

If you respond to a workspace event by starting the work for some plug-in, you won't be competing with background compilation. Background compilation is built to respond to the same events by accessing the same API's you would, causing the compilations to be built. If your plug-in calls the same API's, you'll get the same compilation instance. Just make sure you are not blocking the async API's and are responsive to cancelling your work in progress when then next workspace event occurs, and possibly for expensive work to start it after a delay so it doesn't interfere with typing.

[JoshVarty]

For one project I'm working on called Code Connect we display a static call graph to the user at design-time. As the user adds/removes invocations, the call graph updates automatically.

RegisterCodeBlockEndAction looks like it might be useful for this purpose. Currently we've had to build a custom differencing engine to find the differences between two files and then look within method bodies for added/removed invocations.

RegisterSyntaxNodeAction Might also be useful as well. It would allow us to operate only on MethodDeclarationSyntax and completely ignore changes to things like Fields and Comments (for which the WorkspaceChanged event still fires).

I guess it feels like there's a lack of granularity to the changes we can listen to.

[JoshVarty]

@mattwar My fears about performance might have been misplaced. (We haven't run into any issues with performance or anything).

[mattwar]

The analysis engine is one of those expensive work items that gets kicked off so the IDE can eventually tell you about diagnostics. It would be perfectly reasonable to subvert the use an analyzer to feed information to your plug-in, its just not the typical use for an analyzer. The workspace events are not meant to convey that level of detail, since it does require much additional work to determine. They are there to tell you about changes to the workspace model itself, changes to projects and documents, but not to the level of detail of the semantic changes in your source code.

[JoshVarty]

The workspace events are not meant to convey that level of detail, since it does require much additional work to determine.

That's understandable. Truth be told, I don't know of any other extensions (other than diagnostics) that would actually need this kind of information and be displaying it in a real-time fashion (ie. reacting to WorkspacedChanged events).

[heejaechang]

workspace event still gives you old and new snapshots of the solution which has a way to give you diff. we also provide a way to diff syntax tree so in a sense it provides all the detail, only difference, I think in actual consumption of data, is that analyzer does many plumbing work for you but workspace just give you data and tool, but it is still you who have to do all the plumbing to get to actual information you are interested in.

I guess, we could have another central event mechanism which do things like register for type added, deleted, a kind of node added, removed and etc. so user doesnt need to do all those plumbing himself. and do bunch of performance work to make sure it doesn't affect typing.

[jasonmalinowski]

@heejaechang Would the incremental analyzer stuff be good enough for what he wants?

[mattwar]

I think he wanted the simplicity of analyzer API where you just register for a particular kind of event, and these events might be when a declaration node is changed, added or removed. So the incremental analyzer stuff, which is a more general plug-in abstraction that the IDE diagnostic analyzer engine is built on is probably not the right level of abstraction, directly, but may be the right place to build out another engine that does what he wants.

[heejaechang]

probably it requires some changes (since it currently loses diff info quite early) but could be supported. but regardless where it is implemented, it seems good thing to support centrally since diff is expensive. if multiple people do diffing themselves, we might waste a lot CPU just for diffing.

[JoshVarty]

@heejaechang I agree that independent diffing seems like a waste.

However, this should probably only be implemented if other extension creators actually need this functionality. If I'm the only one asking for it, it may not be worth the development time. :)

[suprak]

I would like to chime in and say that having the ability to know when a document has compiled (event) would be very useful for my process as well.

I'm also developing a hybrid VS-Extension and Diagnostic Analyzer application.
Basically I need to know when it's safe (low performance hit) to use CompilationWithAnalyzers to determine which of my Analyzers have found Diagnostics and then dress them up.

[mattwar]

@suprak, what does it mean to have a document be compiled? Do you mean when all other analyzers have run? Typically as much work is avoided as possible on individual compilations as new ones are created each keystroke. All semantics (including diagnostics) are computed only on request, asynchronously. The diagnostics engine that VS uses (similar to CompilationWithAnalyzers), is typically the one that asks, but it is built to delay asking until the user is no longer typing.

[CyrusNajmabadi]

Closing this out. We have no plan on doing this and we woudl need a solid API proposal (or even a reasonable sketch), along with a good discussion that shows that such an API can be implemented efficiently and will cause no scaling issues in the sizes of projects roslyn works with.