-
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
Add class as a target for RequiresUnreferencedCodeAttribute #50122
Comments
Tagging subscribers to 'linkable-framework': @eerhardt, @vitek-karas, @LakshanF, @tannergooding, @sbomer Issue DetailsBackground and MotivationAs explained in dotnet/linker#1742 some types are considered not trim compatible leading to mark all its member methods with RequiresUnreferencedCode. This could lead to hundreds of members annotated with RequiresUnreferencedCode. The proposal is to only annotate the type with RequiresUnreferencedCode, then the linker will treat this as if we annotated constructors and static methods with RequiresUnreferencedCode. Proposed API- [System.AttributeUsageAttribute(System.AttributeTargets.Constructor | System.AttributeTargets.Method, Inherited=false)]
+ [System.AttributeUsageAttribute(System.AttributeTargets.Class | System.AttributeTargets.Constructor | System.AttributeTargets.Method, Inherited=false)]
#if SYSTEM_PRIVATE_CORELIB
public
#else
internal
#endif
sealed class RequiresUnreferencedCodeAttribute : Attribute Usage Examples[RequiresUnreferencedCode ("Class MyType has been marked as dangerous for trimming", Url = "https://helpurl/MyType")]
public class MyType {
public static void M1 () {}
public static void M2 () {}
}
public class OtherType {
public void Main () {
M1(); -> This creates a warning IL2026
M2(); -> This creates a warning IL2026
}
} Alternative DesignsApply to other AttributeTargets like struct and interface. As per @MichalStrehovsky comments, Structs are problematic because they can be default-instantiated. We would like this to be considered unsafe (and warn) only if a constructor or a static method on the type is called to limit the amount of noise (and additional suppressions needed) when a type is annotated as such. Since this enhancement is meant to help people to annotate fewer methods seems to be a good option to start just by enabling it in classes, but this issue is meant to discuss which targets we want to enable. RisksRelated to #50064
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Tagging subscribers to this area: @vitek-karas, @agocke, @CoffeeFlux, @VSadov Issue DetailsBackground and MotivationAs explained in dotnet/linker#1742 some types are considered not trim compatible leading to mark all its member methods with RequiresUnreferencedCode. This could lead to hundreds of members annotated with RequiresUnreferencedCode. The proposal is to only annotate the type with RequiresUnreferencedCode, then the linker will treat this as if we annotated constructors and static methods with RequiresUnreferencedCode. Proposed API- [System.AttributeUsageAttribute(System.AttributeTargets.Constructor | System.AttributeTargets.Method, Inherited=false)]
+ [System.AttributeUsageAttribute(System.AttributeTargets.Class | System.AttributeTargets.Constructor | System.AttributeTargets.Method, Inherited=false)]
#if SYSTEM_PRIVATE_CORELIB
public
#else
internal
#endif
sealed class RequiresUnreferencedCodeAttribute : Attribute Usage Examples[RequiresUnreferencedCode ("Class MyType has been marked as dangerous for trimming", Url = "https://helpurl/MyType")]
public class MyType {
public static void M1 () {}
public static void M2 () {}
}
public class OtherType {
public void Main () {
M1(); -> This creates a warning IL2026
M2(); -> This creates a warning IL2026
}
} Alternative DesignsApply to other AttributeTargets like struct and interface. As per @MichalStrehovsky comments, Structs are problematic because they can be default-instantiated. We would like this to be considered unsafe (and warn) only if a constructor or a static method on the type is called to limit the amount of noise (and additional suppressions needed) when a type is annotated as such. Since this enhancement is meant to help people to annotate fewer methods seems to be a good option to start just by enabling it in classes, but this issue is meant to discuss which targets we want to enable. RisksRelated PRRelated to #50064
|
namespace System.Diagnostics.CodeAnalysis
{
[AttributeUsage(
+ AttributeTargets.Class |
AttributeTargets.Constructor |
AttributeTargets.Method,
Inherited = false)]
public sealed class RequiresUnreferencedCodeAttribute : Attribute
{
}
} |
Closing via #50064 |
Background and Motivation
As explained in dotnet/linker#1742 some types are considered not trim compatible leading to mark all its member methods with RequiresUnreferencedCode. This could lead to hundreds of members annotated with RequiresUnreferencedCode. The proposal is to only annotate the type with RequiresUnreferencedCode, then the linker will treat this as if we annotated constructors and static methods with RequiresUnreferencedCode.
Proposed API
namespace System.Diagnostics.CodeAnalysis { [AttributeUsage( + AttributeTargets.Class | AttributeTargets.Constructor | AttributeTargets.Method, Inherited = false)] public sealed class RequiresUnreferencedCodeAttribute : Attribute { } }
Usage Examples
Alternative Designs
Apply to other AttributeTargets like struct and interface. As per @MichalStrehovsky comments, Structs are problematic because they can be default-instantiated. We would like this to be considered unsafe (and warn) only if a constructor or a static method on the type is called to limit the amount of noise (and additional suppressions needed) when a type is annotated as such.
If we allow this on structs, we would have to warn on instance methods too, plus it would introduce problems when unsafe instance methods get called indirectly through interfaces (the tool would not be able to see that at all).
Since this enhancement is meant to help people to annotate fewer methods seems to be a good option to start just by enabling it in classes, but this issue is meant to discuss which targets we want to enable.
Risks
Related PR
Related to #50064
The text was updated successfully, but these errors were encountered: