-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Address unused suppressions #89216
Address unused suppressions #89216
Conversation
<Suppressions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> | ||
<Suppression> | ||
<DiagnosticId>CP0001</DiagnosticId> | ||
<Target>T:System.Runtime.InteropServices.JavaScript.WebWorker</Target> |
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 it looks like this is implementation-only API that's only present in one implementation assembly. Since it's excluded from the ref that means it's not a problem for users. Make the suppression conditional as well so that we don't fail the new unused suppressions check.
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.
Thanks!
Although it looks like it's failing ApiCompat. EagerStaticClassConstructionAttribute can be made private to corelib, we don't use it outside corelib and the only reason why it's public is probably some .NET Native history. DebuggerGuidedStepThroughAttribute is used outside corelib. This attribute is used in pair with System.Diagnostics.DebugAnnotations that is also in the suppression. We could either move this to the plan where we make it private and source include the file from multiple assemblies (these are matched by name, they don't need to be in corelib), or keep the suppression. |
We've got some new API compat errors that popped up on Friday. Can those be addressed here as well? |
I'll put a separate PR for those. I think this one is just about ready to merge. Ideally we could also get the new APICompat in build so that we can hold the line on these issues. @ViktorHofer |
Tracking issue: #88675 |
The one failure was a test issue which I filed. |
Fix #89206