-
Notifications
You must be signed in to change notification settings - Fork 229
Verify C# diagnostics in CodeGenerationIntegrationTest
#10337
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
49c353b to
246cfba
Compare
333fred
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.
I've gone through a few of the test files, but I'll put off going through them all until my other questions are sorted to avoid any churn that results. Overall, this is looking good, and I'm super happy to see it. Thanks for the effort Jan!
...r/Microsoft.AspNetCore.Razor.Language/test/IntegrationTests/CodeGenerationIntegrationTest.cs
Outdated
Show resolved
Hide resolved
...ared/Microsoft.AspNetCore.Razor.Test.Common/Language/IntegrationTests/IntegrationTestBase.cs
Show resolved
Hide resolved
...ared/Microsoft.AspNetCore.Razor.Test.Common/Language/IntegrationTests/IntegrationTestBase.cs
Outdated
Show resolved
Hide resolved
...ared/Microsoft.AspNetCore.Razor.Test.Common/Language/IntegrationTests/IntegrationTestBase.cs
Outdated
Show resolved
Hide resolved
333fred
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.
![]()
|
@chsienki @dotnet/razor-compiler for a second review, thanks |
chsienki
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.
LGTM. Consider moving the class properties onto the IntegrationTestFact if we think there will be more of these or keep as-is if these are expected to be very limited.
| { | ||
| // C# 8 features are not available in .NET Framework without polyfills | ||
| // so the C# diagnostics would be different between .NET Framework and .NET Core. | ||
| SkipVerifyingCSharpDiagnostics = ExecutionConditionUtil.IsDesktop; |
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.
Did you consider making these optional params to the IntegrationTestFact? So we could have e.g. [IntegrationTestFact(SkipVerifyingCSharpDiagnostics = 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.
Hm, haven't considered that, sounds interesting. But it looks like it would be much more difficult to propagate these options down to the IntegrationTestBase methods where I need them. If I understand correctly, I would need to add new properties to IntegrationTestFact, then add new parameters to constructors of each test class, then pass the properties as constructor arguments in IntegrationTestCase. Maybe there's a simpler way? But still, for end-user the effect would be just moving something like SkipVerifyingCSharpDiagnostics = ExecutionConditionUtil.IsDesktop; from the test body into the attribute which doesn't seem worth the effort here. So I think I will leave as is. But happy to change this in a follow up if I misunderstood :)
Part of #10247.
I will look into verifying C# diagnostics in other tests as well, but I wanted to get some early feedback before I continue.
I have changed the tests to reference MVC shims, added more razor compiler passes, and more things to avoid many noisy diagnostics. But note that many errors still remain in many of them because they were simply never written to successfully compile. But I think that's fine for baselines - we should be just cautious when in future some PRs add to the diagnostics.
Also if you prefer to not change the tests at all and have more noisy diagnostics as baselines instead, I can do that too.