Skip to content

Conversation

@dibarbet
Copy link
Member

@dibarbet dibarbet commented Jun 20, 2022

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

@ghost ghost added the Area-IDE label Jun 20, 2022
@dibarbet dibarbet force-pushed the split_correctness_analyzers branch from 4937bf3 to 21e9027 Compare June 21, 2022 00:25
Copy link
Member

@Youssef1313 Youssef1313 left a 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

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"}
?

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"
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Member Author

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

@dibarbet
Copy link
Member Author

Should -runAnalyzers:$true be removed from

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"}

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

@dibarbet dibarbet force-pushed the split_correctness_analyzers branch from 21e9027 to 68d1c05 Compare June 21, 2022 18:30
@jmarolf
Copy link
Contributor

jmarolf commented Jun 21, 2022

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

@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.

@dibarbet dibarbet marked this pull request as ready for review June 21, 2022 18:32
@dibarbet dibarbet requested a review from a team as a code owner June 21, 2022 18:32
@dibarbet dibarbet requested a review from RikkiGibson June 21, 2022 18:39
@jaredpar
Copy link
Member

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"
Copy link
Member

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."

Copy link
Contributor

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.

@RikkiGibson
Copy link
Member

It's slightly disconcerting that the build_analyzers leg is failing but the correctness_build leg is passing :)

@dibarbet
Copy link
Member Author

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).

@RikkiGibson
Copy link
Member

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?

@dibarbet
Copy link
Member Author

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

@dibarbet dibarbet requested review from a team as code owners June 22, 2022 22:44
@dibarbet
Copy link
Member Author

@RikkiGibson @dotnet/roslyn-compiler for compiler review - had to update to a new version of the analyzer / formatter which added new warnings.

Copy link
Member

@RikkiGibson RikkiGibson left a 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.

@dibarbet
Copy link
Member Author

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.

@JoeRobich
Copy link
Member

/azp run roslyn-CI

@azure-pipelines
Copy link

Azure Pipelines failed to run 1 pipeline(s).

@JoeRobich
Copy link
Member

/azp run roslyn-CI

@azure-pipelines
Copy link

Azure Pipelines failed to run 1 pipeline(s).

@dibarbet
Copy link
Member Author

@RikkiGibson is now a good time to merge this?

@dibarbet
Copy link
Member Author

talked to @333fred offline since Rikki is OOF - going ahead with merge.

@jmarolf you should be able to pull this into yours now

@dibarbet dibarbet merged commit 0146540 into dotnet:main Jul 29, 2022
@dibarbet dibarbet deleted the split_correctness_analyzers branch July 29, 2022 00:50
@ghost ghost added this to the Next milestone Jul 29, 2022
@dibarbet dibarbet modified the milestones: Next, 17.4 P2 Sep 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants