-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Add correctness check that only runs analyzers #62035
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
4937bf3 to
21e9027
Compare
Youssef1313
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should -runAnalyzers:$true be removed from
roslyn/eng/test-build-correctness.ps1
Line 46 in 29a29d5
| Exec-Block { & (Join-Path $PSScriptRoot "build.ps1") -restore -build -bootstrap -bootstrapConfiguration:Debug -ci:$ci -runAnalyzers:$true -configuration:$configuration -pack -binaryLog -useGlobalNuGetCache:$false -warnAsError:$true -properties "/p:RoslynEnforceCodeStyle=true"} |
azure-pipelines.yml
Outdated
| displayName: Build with analyzers | ||
| inputs: | ||
| filePath: eng/build.ps1 | ||
| arguments: -restore -build -configuration Release -prepareMachine -ci -binaryLog -runAnalyzers:$true -warnAsError:$true -properties "/p:RoslynEnforceCodeStyle=true" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to build using both Debug and Release? I can imagine an analyzer reporting a diagnostic inside #if DEBUG that won't be caught if we're building in Release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think its worth running both to be honest, we've already cut down our CI a fair amount to reduce chances for flakiness. However I do see that we have wayyy more #if DEBUG than release ones, so I'm definitely open to running this in Debug instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The compiler uses debug pragmas a lot. On the IDE side we use significantly less (about 10% of what the compiler does) but we still use them. However, all of our Debug pragmas are additive so if we run the analyzer leg in Debug I think that should be all we need.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated to use debug mode instead
This is a question I also wanted to ask @jmarolf - I'm not sure if we want to execute analyzers in the bootstrap compiler to make sure there aren't analyzer bugs, so I left it in |
21e9027 to
68d1c05
Compare
@dibarbet yeah, there are compiler assertions that get hit by running analyzers. The intent of this was to be a stress-test of the compiler so I think we should leave it in. |
Yep this is the reason. Correctness is meant as a full stress test on "can we keep compiling Roslyn with these changes to the compiler". |
| displayName: Build with analyzers | ||
| inputs: | ||
| filePath: eng/build.ps1 | ||
| arguments: -restore -build -configuration Debug -prepareMachine -ci -binaryLog -runAnalyzers:$true -warnAsError:$true -properties "/p:RoslynEnforceCodeStyle=true" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So getting all analyzer diagnostics in the solution on the command line requires emitting, etc.? is that correct? Just wondered if there was an msbuild target or something equivalent to "run code analysis on solution."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
someday when we are allowed to used github actions we could use: https://github.com/dotnet/code-analysis but for now I think this is the simplest approach.
|
It's slightly disconcerting that the build_analyzers leg is failing but the correctness_build leg is passing :) |
It is, I am investigating. It appears as though the analyzers leg is reporting formatting errors on raw string literals. These formatting errors are not reported in the IDE and seem to not be reported in the correctness leg. I wonder if potentially the build with analyzers is using an outdated analyzer/compiler that doesn't support them? As best as I can tell the formatting seems ok (for example an error is reported here - https://github.com/dotnet/roslyn/blob/main/src/Compilers/Test/Core/BaseCompilerFeatureRequiredTests.cs#L29). |
|
We use the same version of the analyzers in both bootstrap and non bootstrap builds right? Is there possibly an API behavior difference in bootstrap that accounts for the formatting issue? |
I think this is what was happening - now that I've upgraded to newer versions of the analyzers / formatter, I see a new set of warnings that are the same in both the correctness and analyzers leg. I'm going to add fixes for those to the PR |
|
@RikkiGibson @dotnet/roslyn-compiler for compiler review - had to update to a new version of the analyzer / formatter which added new warnings. |
RikkiGibson
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to take this, though would suggest we wait another week or two for the compiler's outstanding feature branches to merge back in. Don't want any formatting issues added in there to impede progress right now.
Fine with me, just lmk when they are merged in so I can update this PR. |
|
/azp run roslyn-CI |
|
Azure Pipelines failed to run 1 pipeline(s). |
|
/azp run roslyn-CI |
|
Azure Pipelines failed to run 1 pipeline(s). |
|
@RikkiGibson is now a good time to merge this? |
It isn't uncommon for me to push changes to a PR and then an hour later notice that the correctness build fails due to formatting errors. This splits out the analyzers run from correctness so that we can more quickly get analysis results without having to wait for the longest CI leg to complete.
I know @CyrusNajmabadi also hits this regularly