Enforce analyzer consistency in our builds#43954
Conversation
This changes the bootstrap compiler to enforce that our build doesn't suffer from analyzer consistency issues. This will prevent us from introducing build performance issues into the repository in the future. Essentially adding enforcement to make sure that PRs like dotnet#43629 won't ever be necessary again. Related to dotnet#43629
|
🎉 |
|
Validated locally that if I build without @sharwell fix that I get an error because of inconsistent analyzers: I actually get several errors. |
| // a lot of false positives. The current value was chosen as a reasonable number for warranting an | ||
| // investigation. | ||
| if (s_failedServerConnectionCount > 20) | ||
| const int maxRejectCount = 5; |
There was a problem hiding this comment.
Are we confident in going from 20 => 5 for the non detectable errors?
There was a problem hiding this comment.
Yes. Now this should only happen where there is basically a named pipe issue in our build. If there are more than 5 on a regular basis we can kick the number back up.
| switch (tuple.ResponseType) | ||
| { | ||
| case ResponseType.AnalyzerInconsistency: | ||
| Log.LogError($"Analyzer inconsistency building {tuple.OutputAssembly}"); |
There was a problem hiding this comment.
How do we know which analyzers had inconsistencies when this happens? Are other diagnostic messages printed in this scenario?
There was a problem hiding this comment.
No. There are no other diagnostics.
At the moment this isn't a user visible diagnostic. This is deliberately an implementation detail because this can happen in completely well functioning build. Surfacing a real diagnostic here would essentially be giving users false and unactionable information.
In this very specific scenario, a controlled bootstrap build, we know that this is wrong and hence we can emit an error.
This changes the bootstrap compiler to enforce that our build doesn't
suffer from analyzer consistency issues. This will prevent us from
introducing build performance issues into the repository in the future.
Essentially adding enforcement to make sure that PRs like #43629 won't
ever be necessary again.
Related to #43629