RequiresDynamicCode analyzer should understand RuntimeFeature.IsDynamicCodeSupported

[MichalStrehovsky]

Even though M1 below calls a method annotated RequiresDynamicCode, it does so in a code path that is not reachable at runtime when dynamic code is not supported. We should not generate a warning.

static void M1()
{
    if (RuntimeFeature.IsDynamicCodeSupported)
    {
        M2();
    }
}

[RequiresDynamicCode("...")]
static void M2()
{
}

Cc @tlakollo

[sbomer]

Related is a similar issue for feature switches in the linker - there it's a problem both for the trim analyzer, and when trimming libraries in "library mode" where the feature switches aren't baked in. This is the issue I mentioned in #2004 (comment).

On the linker side I think this is +1 to the refcount for moving feature switch definitions out of XML. Otherwise we would need to add support to the analyzer for reading XML, which we have been trying so hard to avoid.

[MichalStrehovsky]

Yep, this could be a special case of feature switch support.

I think a problem that we'll run into as we're trying to generalize this is the constant propagation across methods that illink is doing - the constant propagation affects the analysis that happens within illink, but it's not something we can fully emulate in the analyzer - we can do at most one level.

I've had mixed feelings about the multi-layer constant propagation - one one hand I understand the problem constant propagation is trying to solve, but on the other hand I wish we instead worked on refactorings within framework so that we don't need to constant propagate across more than one level (e.g. if someone wraps RuntimeFeature.IsDynamicCodeSupported in a wrapper method and then calls that wrapper and expects the bool to get propagated across 2 methods).

[marek-safar]

I wish we instead worked on refactorings within framework so that we don't need to constant propagate across more than one level

I don't think that would solve the problem either. I'm not sure if with the existing analyzers design we can solve this effectively because the analyzer works with assembly references hence have a minimal understanding of what external dependencies do.

[MichalStrehovsky]

I wish we instead worked on refactorings within framework so that we don't need to constant propagate across more than one level

I don't think that would solve the problem either. I'm not sure if with the existing analyzers design we can solve this effectively because the analyzer works with assembly references hence have a minimal understanding of what external dependencies do.

It would require a combination of what Sven wrote (feature switches encoded as custom attributes) + only doing one level of constant propagation. We would then see that RuntimeFeature.IsDynamicCodeSupported is a constant even from a ref assembly and be able to handle it as such in the analyzer.

[eerhardt]

Should the same rule apply to RuntimeFeature.IsDynamicCodeCompiled?

I assume I shouldn't get an error there because using the "AOT-unfriendly" API is behind a RuntimeFeature.IsDynamicCodeCompiled switch.

[MichalStrehovsky]

Yeah, IsDynamicCodeCompiled would never be true if IsDynamicCodeSupported is false, so this should also be treated as unreachable code in full-AOT-with-no-fallbacks modes.