Add RequiresUnreferencedCodeAttribute

This is in support of dotnet/linker#988 - see the spec there for motivation.

Potentially might want to call this something like RequiresFormFactorAttribute with a FormFactor enum. We'll want similar attributes to mark things that are unfriendly to AOT or unfriendly to single-file deployments.

namespace System.Runtime.CompilerServices
{
    [AttributeUsage(
        AttributeTargets.Method |
        AttributeTargets.Class |
        AttributeTargets.Struct |
        AttributeTargets.Constructor |
        AttributeTargets.Assembly)]
    public sealed class RequiresUnreferencedCodeAttribute : Attribute
    {
        public RequiresUnreferencedCodeAttribute(string message)
        {
            Message = message;
        }

        public string Message { get; }
    }
}

We definitely need a better name... "FormFactor" sounds OK to me, but I'm not sure about "unsafe".

I would also start with only allowing this on methods. If we see a need to put this on other things we can expand later on. I just fear that defining the correct behavior for this on things like assemblies will be relatively tricky.

@eerhardt

/cc @eerhardt

For naming, I'd rather the attribute describe what the condition is rather than its effects, e.g. [ReflectsOnInput(parameterName)]. That then can be interpreted both by tools and by developers calling this method and themselves needing to understand what about the target they need to then protect so that their method can be considered linker safe.

For naming, I'd rather the attribute describe what the condition is rather than its effects, e.g. [ReflectsOnInput(parameterName)].

That's what the proposal for DynamicallyAccessedMembersAttribute is about - #33861.
This attribute here is for cases where it's not possible to point to a parameter/data or it simply doesn't make sense. It's also not only about reflection going forward. Examples:

Assembly.Location for single-file correctness
Assembly.LoadFrom for linker friendliness (since it loads code linker has never seen, it is potentially problematic)
Reflection.Emit for AOT scenarios without a JIT/interpreter
...

We also plan to use this as a band aid for cases which the linker doesn't support yet, or for cases where the DynamicallyAccessedMembersAttribute will not be good enough.

There should also eventually be "LinkerFriendly" attribute - among other things also as a band-aid for cases where the linker finds something wrong, but it's not.

Ok, but that's missing my point. And your examples highlight that, as several of them are not about the linker, and "form factor" is ambiguous (that can, for example, refer to whether an app's UI is designed for a phone, a tablet, a desktop, etc.)

I absolutely agree that it's not just about a linker and that we need to find a better name if we're going to use the same attribute for all of these cases. We could also have multiple attributes each covering one of these scenarios.

We could also have multiple attributes each covering one of these scenarios.

I think we need to. e.g. If all I care about is trimming to make my app smaller, why would I want warnings about things that might not work only if I was targeting AOT? This also speaks to why I think attributes should be named very specifically; they can describe the what, and a tool can then decide whether that condition is relevant to its needs. If the attribute instead speaks to a specific tool, other tools need to guess why and whether it's relevant to them.

If all I care about is trimming to make my app smaller, why would I want warnings about things that might not work only if I was targeting AOT?
Linker should only warn about things which are applicable to the current configuration. So if the app being built is not asking for AOT or Single-File linker should not warn about those. That said adding the ability to detect issues with AOT/Single-File/... is still very much in "thinking about it" as we don't have a specific designs.

About the trim-only attribute (if we decide to go with that) - I still think we should have a generic "band aid" attribute for cases which we don't have better attributes for. But maybe it can be something relatively specific like [HasDynamicBehavior("Loading assemblies can lead to breaks static analysis is required for the app")] (I don't know, bad with names) - something which would not be tool specific, but would also be "generic" enough.

Renamed this to RequiresUnreferencedCodeAttribute per discussion with Vitek. I expect this to change again during the review, but this is what we'll try to go with.

Since this is supposed to be applied by hand, the namespace should be System.Diagnostics.CodeAnalysis
- We may want to bulk review and move the linker-inspired new attributes for .net 5 into a new namespace.
Add a Url parameter
The AttributeTargets should either only include methods (and ctors) or all of the container types above methods, not just some of them.
- It sounds like trimming to just methods is preferred by the tooling team.

namespace System.Diagnostics.CodeAnalysis
{
    [AttributeUsage(
        AttributeTargets.Method |
        AttributeTargets.Constructor,
      Inherited = false,
      AllowMultiple = false)]
    public sealed class RequiresUnreferencedCodeAttribute : Attribute
    {
        public RequiresUnreferencedCodeAttribute(string message)
        {
            Message = message;
        }

        public string Message { get; }
        public string Url { get; set; }
    }
}

Add RequiresUnreferencedCodeAttribute (#36674)

[Automated PR] master -> dev/infrastucture (#37086)

Navigation Menu

Repository navigation

Add RequiresUnreferencedCodeAttribute #33862

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add RequiresUnreferencedCodeAttribute #33862

Description

Activity

vitek-karas commented on Mar 20, 2020

vitek-karas commented on Mar 20, 2020

stephentoub commented on Mar 23, 2020

vitek-karas commented on Mar 23, 2020

stephentoub commented on Mar 23, 2020

vitek-karas commented on Mar 23, 2020

stephentoub commented on Mar 23, 2020

vitek-karas commented on Mar 23, 2020

7 remaining items

MichalStrehovsky commented on Apr 23, 2020

bartonjs commented on Apr 30, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions