Respect the new DynamicDependencyAttribute

[eerhardt]

The official public API for PreserveDependencyAttribute was renamed to DynamicDependencyAttribute. Also a MemberTypes property was added to DynamicDependencyAttribute.

We should respect this new attribute in the linker.

See dotnet/runtime#30902 for discussion.

[marek-safar]

I think for illink we could drop support for the internal PreserveDependencyAttribute and support only the new public attribute. It'd be also better to move the data extraction logic from MarkStep to PreserveDependencyLookupStep to allow printing info about wrong references consistently.

@sbomer could you work on this (/cc @vitek-karas) ?

[sbomer]

Part of this will involve defining the wildcard behavior. Currently:

• ResolveFromXmlStep allows "*" anywhere in a type pattern, which will match any sequence of characters in a type's full name.
  • It doesn't support wildcards on member signatures - but it does support keeping all methods with the same name.
• PreserveDependencyAttribute allows a signature equal to "*", which will cause the corresponding type to be kept in its entirety.
  • It doesn't support wildcards that match parts of a signature, or wildcards on the type part.

For consistency, I think we should make both support the same syntax. The design review for the attribute gives this example as a reason why we need wildcards for the attribute - in this case, on the type.

Does the following behavior sound ok? See the updated suggestion at the end.

• Support "*" anywhere in a type pattern or member signature, for both ResolveFromXmlStep, and in DynamicDependencyAttribute when the type/member are given as strings.

This will allow selecting multiple types, and also multiple members of those types at the same time.

edit: Actually, since we're adding overloads to the attribute that take DynamicallyAccessedMemberTypes, that seems unnecessary. How does this sound?

• Support "*" anywhere in a type pattern, but not member signatures. Remove support for wildcard in signatures from DynamicDependencyAttribute.

[vitek-karas]

My understanding of the API review result was that we don't want to support wildcards and that we're replacing that functionality with the .ctor overloads which take DynamicallyAccessedMemberTypes - for example.

This probably means that it would be nice to refactor bits of the existing support in the data flow code such that we can use one place which understands the DynamicallyAccessedMemberTypes enum and knows how to apply it to types.

[marek-safar]

I agree with Vitek that the wildcards support was not agreed/spec-ed enough to be implemented.

[vitek-karas]

This should be fixed by #1215