Description
Historically the analysis of RequiresAssemblyFiles was made via an analyzer. The attribute can be placed in properties and events and its meaning is that if placed directly on the property/event then all the methods being declared in the property/event are considered to be annotated as RequiresAssemblyFiles. From the Roslyn compiler standpoint, the analysis can trivially be initiated from a property, event or a method using callbacks.
IL-based tools like linker and NativeAOT by default have access to the methods accessors and require additional processing to find the associated property or event. Therefore attributes like RequiresUnreferencedCode and RequiresDynamicCode were explicitly not allowed in property or events since from the standpoint of IL is just easier to operate directly with the method accessor.
One of the requirements of NativeAOT is being SingleFile safe, since the final output of the compiler is a single file. Given this restriction, the NativeAOT compiler now detects and warns about RequiresAssemblyFiles. This means that the NativeAOT compiler now needs a way to detect the associated property/event of a determined property/event accessor.
Given that we will have to implement a way to track the associated property/event we might as well add them as targets in the AttributeUsage of RequiresUnreferencedCode and RequiresDynamicCode.
Reproduction Steps
public class C {
public static void Main() {
SomeProperty = "HelloWorld";
Console.WriteLine(SomeProperty);
}
[RequiresAssemblyFiles ("Message")]
public static string SomeProperty { get; set; }
}
Expected behavior
Access to method accessors from a property/event annotated with Requires should generate a warning
Actual behavior
Only if the annotation is the method accessor the warning is generated
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response
Description
Historically the analysis of RequiresAssemblyFiles was made via an analyzer. The attribute can be placed in properties and events and its meaning is that if placed directly on the property/event then all the methods being declared in the property/event are considered to be annotated as RequiresAssemblyFiles. From the Roslyn compiler standpoint, the analysis can trivially be initiated from a property, event or a method using callbacks.
IL-based tools like linker and NativeAOT by default have access to the methods accessors and require additional processing to find the associated property or event. Therefore attributes like RequiresUnreferencedCode and RequiresDynamicCode were explicitly not allowed in property or events since from the standpoint of IL is just easier to operate directly with the method accessor.
One of the requirements of NativeAOT is being SingleFile safe, since the final output of the compiler is a single file. Given this restriction, the NativeAOT compiler now detects and warns about RequiresAssemblyFiles. This means that the NativeAOT compiler now needs a way to detect the associated property/event of a determined property/event accessor.
Given that we will have to implement a way to track the associated property/event we might as well add them as targets in the AttributeUsage of RequiresUnreferencedCode and RequiresDynamicCode.
Reproduction Steps
public class C {
public static void Main() {
SomeProperty = "HelloWorld";
Console.WriteLine(SomeProperty);
}
}
Expected behavior
Access to method accessors from a property/event annotated with Requires should generate a warning
Actual behavior
Only if the annotation is the method accessor the warning is generated
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response