Decorate statically-known dynamic dependencies with DynamicDependency

[IS4Code]

There are situations on the boundary between static and dynamic dispatch, where a particular member is statically known to be accessed, but the access is dynamic, such as when invoking members with dynamic arguments:

class Program
{
    public static void Main()
    {
        var c = new C();
        dynamic val = 1;
        _ = c[val];
        c.Method(val);
    }
}

class C
{
    public object? this[int index] { get => null; }
    
    public void Method(int arg)  { }
}

Changing var c to dynamic c has absolutely no effect on the generated CIL code, but the compiler is aware of the dependency, and will issue errors if the members in C are removed.

I think that in situations like this one, where the compiler is aware of the dependency but cannot express it in code, it should add the DynamicDependency attribute to the method that uses the members, preventing potential issues as a result of trimming or other analysis:

[DynamicDependency("get_Item", typeof(C))]
[DynamicDependency("Method", typeof(C))]
public static void Main()

[svick]

Personally, I don't see much value in automatically making dynamic sometimes work with linking. Especially since dynamic is quite a niche feature and since a workaround exists (even though manually specifying every DynamicDependency is tedious).

[IS4Code]

I don't think "sometimes working" describes this. This is not calling methods on dynamic, where the compiler cannot reasonably be expected to know the type, this is using statically known methods with dynamic arguments, something the programmer, the IDE, and the compiler treats as non-dynamic access in almost all situations except when generating the corresponding code. Yes, a workaround exists, but it should not have to be maintained by the programmer, especially given it can be triggered by such a "silent" change as changing one argument of a method to dynamic (yes, I know this is an enormous change under the hood, but it is not presented as such).

I am not speaking hypothetically here, I got bit by this, and I am worried about any other assemblies where the programmers might have had similar assumptions, which could silently break during trimming.

[Rekkonnect]

Since manually describing each of these attributes is tedious, having some tooling to automatically include them in the declaration will be beneficial. On the other hand, integrating this as part of the compiler feels a little overboard for such a niche case. Trimmable assemblies rarely use dynamic as I see it. This could make a good case for a third-party source generator, although the restriction is that the generator would only be capable of supporting methods containing dynamic due to requiring them to be partial.