Skip to content

Remove IDE heuristic for IsCompilationEndAnalyzer#48762

Merged
11 commits merged intodotnet:masterfrom
mavasani:IsCompilationEndAnalyzer
Oct 23, 2020
Merged

Remove IDE heuristic for IsCompilationEndAnalyzer#48762
11 commits merged intodotnet:masterfrom
mavasani:IsCompilationEndAnalyzer

Conversation

@mavasani
Copy link
Contributor

Addresses the core functionality part of #47754 (comment).

A follow-up change will address the second part of generating an IDE-only diagnostic when an analyzer reports a diagnostic in CompilationEnd action which does not have the CompilationEnd custom tag.

@Dotnet-GitSync-Bot

This comment has been minimized.

@sharwell
Copy link
Contributor

@mavasani Can you fill in this table?

IDE Warning without FSA IDE Warning with FSA
Analyzer without custom tag
Analyzer with custom tag

@mavasani
Copy link
Contributor Author

@sharwell That is not in scope of this PR - this PR just changes the existing logic for determining if a diagnostic reported from build should be treated as a build-only/compilation-end diagnostic or not. Before this PR, that determination was done by an expensive, fragile heuristic that involves invoking callbacks into the analyzer. After this PR, that determination is done via an explicit custom tag on the diagnostic descriptors registered by the analyzer.

@mavasani
Copy link
Contributor Author

To clarify my comment further - FSA setting is not being used to determine if a build diagnostic determined to be a compilation-end diagnostic should be treated as an intellisense supported diagnostic or not (probably it should be). However, those semantics are not being changed in this PR, so changing anything w.r.t. FSA setting is completely orthogonal to any work being done to resolve #47754

@sharwell
Copy link
Contributor

@mavasani That's fine (and would be fine to indicate in the table what the follow-up behavior will be). I'm mostly trying to understand the impact this will have on users in each of the four states listed above. For each of the four states, the following could be impacted:

  • Behavior after a new solution/file is opened for editing (no prior build or analysis)
  • Behavior when Run Code Analysis is invoked in the IDE
  • Behavior when a file is opened after a build reported compilation end diagnostics
  • Behavior when an analyzer reports diagnostics from normal callbacks and separately registers a compilation end callback

@mavasani
Copy link
Contributor Author

Filed #48793 to track investigating and fixing any build/live de-duping in presence of FSA being on/off. That option is unrelated to this PR and #47754 in general.

@mavasani
Copy link
Contributor Author

mavasani commented Oct 22, 2020

@sharwell I performed bunch of validations and hopefully the results below should give us much stronger confidence in the experience:

Current Experience

  1. FSA enabled: Compilation end diagnostics behave just like regular non-compilation end diagnostics. They are converted from build diagnostics to intellisense diagnostics during build/live de-duping and get properly refreshed by background analysis while editing code.
  2. FSA disabled: Compilation end diagnostics are build-only diagnostics, that only get refreshed on explicit build.

New Experience

Analyzer package with custom tag

Exactly identical to Current Experience above.

Analyzer package without custom tag

  1. FSA enabled: Exactly same as Current Experience above.
  2. FSA disabled: Compilation end diagnostics are reported on build, but only remain in the error list for closed files. As soon as file is opened, these diagnostics disappear from the error list in "Build + Intellisense" setting. The diagnostics still appear in error list when switched to "Build only" setting.

Run Code Analysis command Experience

This command only force completes analysis for the entire project, it does not override FSA setting. For example, if FSA is off, running this command will only force complete non-compilation end actions for the entire project. This is done specifically to ensure that the command plays nicely with background analysis and generates the same diagnostics as if user had opened every file in the project.

@mavasani mavasani marked this pull request as ready for review October 22, 2020 14:33
@mavasani mavasani requested review from a team as code owners October 22, 2020 14:33
@mavasani mavasani requested a review from sharwell October 22, 2020 14:33
/// Indicates that the diagnostic is a compilation end diagnostic reported
/// from a compilation end action.
/// </summary>
public const string CompilationEnd = nameof(CompilationEnd);
Copy link
Contributor Author

@mavasani mavasani Oct 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dotnet/roslyn-compiler This is the only compiler change in this PR (along with the corresponding public API change in below file). Please see #47754 for more context.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Plan is to mark this obsolete (unused) if we ever re-implement the deduplication algorithm to not need it.

@mavasani mavasani added this to the 16.9.P2 milestone Oct 22, 2020
mavasani added a commit to mavasani/roslyn-analyzers that referenced this pull request Oct 22, 2020
…end actions

Required to account for IDE experience for compilation end diagnostics as a consequence of dotnet/roslyn#48762

As many security rules are compilation end diagnostics, I have made the new parameter `isReportedAtCompilationEnd` a required parameter for `SecurityHelpers.CreateDiagnosticDescriptor` helper.
Copy link
Contributor

@cston cston left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Compiler changes LGTM.

Copy link
Member

@333fred 333fred left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Compiler changes LGTM (commit 7)

Copy link
Contributor

@sharwell sharwell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good aside from the concern of a possible test gap

@mavasani
Copy link
Contributor Author

Thanks @sharwell - I have added the requested test.

@ghost
Copy link

ghost commented Oct 23, 2020

Hello @mavasani!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Auto-approval

@ghost ghost merged commit 480acbd into dotnet:master Oct 23, 2020
@ghost ghost modified the milestones: 16.9.P2, Next Oct 23, 2020
@mavasani mavasani deleted the IsCompilationEndAnalyzer branch October 23, 2020 14:44
mavasani added a commit to mavasani/roslyn-analyzers that referenced this pull request Oct 23, 2020
…end actions

Required to account for IDE experience for compilation end diagnostics as a consequence of dotnet/roslyn#48762

As many security rules are compilation end diagnostics, I have made the new parameter `isReportedAtCompilationEnd` a required parameter for `SecurityHelpers.CreateDiagnosticDescriptor` helper.
@allisonchou allisonchou modified the milestones: Next, 16.9.P2 Nov 24, 2020
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants