search

dotnet / roslyn

The Roslyn .NET compiler provides C# and Visual Basic languages with rich code analysis APIs.
https://docs.microsoft.com/dotnet/csharp/roslyn-sdk/
MIT License
18.95k stars 4.02k forks source link

Fix-All should operate at the document level, and should reuse as much as possible between analysis and fixing. #50349

Open CyrusNajmabadi opened 3 years ago

CyrusNajmabadi commented 3 years ago

Related to https://github.com/dotnet/roslyn/issues/50347

A core problem today with Fix-All (beyond just running in different processes) is the duplicative effort between getting diagnostics and then fixing an issue. When getting diagnostics we must get the compilation ready for a project, then analyze all the files, getting semantic models, symbols and tons of binding information per file to compute the result. However, once we report these diagnostics and go to fix any of them, the fixer must redo so much of the same work (not to mention in another process). This includes again producing hte compilation all over agian, then almost certainly getting the semantic model for that file and producing tons of binding information.

It is likely we could vastly speed things up by moving more to a document-based approach for fixing everything. Specifically, when doing a fix all, we could compute diagnostics for individual documents (likely in parallel). Once diagnostics for a document were produced, we would ideally be able to send those immediately to the fixer, keeping the semantic model alive, so that any work the fixer needed to do could benefit from the semantic work already done and cached by the analyzer.

This belief stems from analysis of fix all traces. In those traces we say a tremendous amount of time being used simply to build compilations/semantic-models/bind. This work is definitely redundant as we know we just did exactly that just to produce the diagnostics in the first place. As semantic models are already a great unit of caching, we should see how we leverage that for this space.

sharwell commented 3 years ago

... we would ideally be able to send those immediately to the fixer, keeping the semantic model alive ...

This will only work if we can run code fixes out-of-process. Most of the complexity stems from the fact that some code actions must run in Visual Studio, while others could run anywhere. We don't have a way to serialize code actions for conditional execution in-process, and we don't have a way to mark a code fix as supporting out-of-process execution.

sharwell commented 3 years ago

Marking as blocked on #50347, since we can't even investigate the potential benefits of a change here prior to that work being completed.