Skip to content

NativeAot produces warning for generic instantiation which can't be suppressed #77455

Closed

Description

@sbomer

Description

Instantiating a generic which has DynamicallyAccessedMemberTypes requirements with a type that has members marked RequiresUnreferencedCode correctly produces a warning. However, the warning is not suppressible by RequiresUnreferencedCodeAttribute or UnconditionalSuppressMessageAttribute.

The problem is that the message origin for the warning is an InstantiatedMethod, a type system entity that isn't associated with the calling context. Encountered while porting compiler-generated code tests from the linker as part of #68786.

Reproduction Steps

Publish the following with PublishAot:

using RUC = System.Diagnostics.CodeAnalysis.RequiresUnreferencedCodeAttribute;
using DAM = System.Diagnostics.CodeAnalysis.DynamicallyAccessedMembersAttribute;
using DAMT = System.Diagnostics.CodeAnalysis.DynamicallyAccessedMemberTypes;
using USM = System.Diagnostics.CodeAnalysis.UnconditionalSuppressMessageAttribute;

class Program {
    static void Main() {
        Test();
    }
    [USM("", "IL2026:RequiresUnreferencedCode")]
    [RUC("")]
    static void Test() {
        MethodWithGenericWhichRequiresMethods<TypeWithMethodWithRequires>();
    }
    static void MethodWithGenericWhichRequiresMethods<[DAM(DAMT.All)] T>() {}
}

class TypeWithMethodWithRequires {
    [RUC("")]
 
    static void MethodWithRequires() {}
}

Expected behavior

RequiresUnreferencedCodeAttribute or UnconditionalSuppressMessageAttribute on Test should suppress the warning.

Actual behavior

ILC : Trim analysis warning IL2026: Program.MethodWithGenericWhichRequiresMethods<TypeWithMethodWithRequires>(): Using member 'TypeWithMethodWithRequires.MethodWithRequires()' which has 'RequiresUnreferencedCodeAttribute' can break functionality when trimming application code.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Activity

  1. ghost added
    untriagedNew issue has not been triaged by the area owner
    on Oct 25, 2022
  2. kant2002 commented on Jan 3, 2023

    @kant2002
    Contributor

    This issue was caused by last line with call to GetFlowDependenciesForInstantiation which is called inside MethodGenericDictionaryNode.ComputeNonRelocationBasedDependencies

    public override void GetDependenciesForGenericDictionary(ref DependencyList dependencies, NodeFactory factory, MethodDesc method)
    {
    TypeDesc owningType = method.OwningType;
    if (FlowAnnotations.HasAnyAnnotations(owningType))
    {
    MethodDesc typicalMethod = method.GetTypicalMethodDefinition();
    Debug.Assert(typicalMethod != method);
    GetFlowDependenciesForInstantiation(ref dependencies, factory, method.Instantiation, typicalMethod.Instantiation, method);

    instantiated generic method variable with value Program.MethodWithGenericWhichRequiresMethods<TypeWithMethodWithRequires>() was given as source for depenndency flow analysis which is incorect because actual source of the call is Test method. From my limited understanding when MethodGenericDictionaryNode created information about call site is lost.

  3. ghost added
    in-prThere is an active PR which will close this issue when it is merged
    on Jan 25, 2023
  4. ghost removed
    in-prThere is an active PR which will close this issue when it is merged
    on Jan 25, 2023
  5. ghost removed
    untriagedNew issue has not been triaged by the area owner
    on Jan 25, 2023
  6. vitek-karas commented on Jan 30, 2023

    @vitek-karas
    Member

    The fix has been reverted due to #81358.

  7. ghost added
    untriagedNew issue has not been triaged by the area owner
    on Jan 30, 2023
  8. ghost added
    in-prThere is an active PR which will close this issue when it is merged
    on Feb 2, 2023
  9. ghost removed
    in-prThere is an active PR which will close this issue when it is merged
    on Feb 7, 2023
  10. ghost removed
    untriagedNew issue has not been triaged by the area owner
    on Feb 7, 2023
  11. ghost added
    in-prThere is an active PR which will close this issue when it is merged
    on Feb 20, 2023
  12. ghost removed
    in-prThere is an active PR which will close this issue when it is merged
    on Feb 21, 2023
  13. ghost locked as resolved and limited conversation to collaborators on Mar 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions