search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.66k stars 1.06k forks source link

APICompat attribute handling inaccurate #35542

Open ericstj opened 12 months ago

ericstj commented 12 months ago

Attributes don't participate in binding and binary compatibility in the same way as types/members. Attributes are consumed by other tools and runtime technology and interpreted differently on a case-by-case basis.

APICompat is ignorant of this and tries to help by just asserting that attributes should remain and be unchanged. In some cases this is helpful, but in a lot of cases it create noise and degrades the experience when working with APICompat.

We were aware of this when adding the AttributesMustMatch rule, which is why it's opt-in and configurable with a list of attributes, but we never tracked improving this.

I think that for many attributes we can promote them to non-optional rules and make them on-by-default. Examples are AttributeUsage, StructLayout, TypeConverter, SupportedOSPlatform, Obsolete. When promoting an attribute to have a special-purpose rule we should omit it from the AttributesMustMatch rule.

Other things to consider when addressing this -- should we introduce more information in the AttributesMustMatch diagnostics to make suppressions more targetable, or is a list of attribute exclusions good enough? Ensure we consider the differences in strict vs compatible comparisons -- these seem straightforward for all the cases mentioned above.

ghost commented 12 months ago

@dotnet/area-infrastructure-libraries a new issue has been filed in the ApiCompat area, please triage

ericstj commented 11 months ago

https://github.com/dotnet/sdk/issues/18681 tracks the fix for better handling of all nullable attributes.