is there a way to not show native AOT warnings for statically inaccessible code during build?

[maumar]

Consider the following snippet in a project marked for Native AOT publish (<PublishAot>true</PublishAot> but the same happens for <IsAotCompatible>true</IsAotCompatible>)

if (true)
{
    Console.WriteLine("ok");
}
else
{
    Console.WriteLine("dead code");
    var myType2 = typeof(List<>).MakeGenericType(typeof(bool));
    Console.WriteLine(myType2);
}

When I build it, I get the following build output:

1>------ Rebuild All started: Project: AotErrorsThatShouldntBeThere, Configuration: Debug Any CPU ------
1>C:\Program Files\dotnet\sdk\8.0.400-preview.0.24276.1\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(311,5): message NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
Restored D:\Projects\AotErrorsThatShouldntBeThere\AotErrorsThatShouldntBeThere.csproj (in 13 ms).
1>D:\Projects\AotErrorsThatShouldntBeThere\Program.cs(11,5,11,12): warning CS0162: Unreachable code detected
1>D:\Projects\AotErrorsThatShouldntBeThere\Program.cs(12,19,12,63): warning IL3050: Using member 'System.Type.MakeGenericType(params Type[])' which has 'RequiresDynamicCodeAttribute' can break functionality when AOT compiling. The native code for this instantiation might not be available at runtime.
1>AotErrorsThatShouldntBeThere -> D:\Projects\AotErrorsThatShouldntBeThere\bin\Debug\net8.0\AotErrorsThatShouldntBeThere.dll
1>Done building project "AotErrorsThatShouldntBeThere.csproj".

Is there a way to not show the warning IL3050: Using member 'System.Type.MakeGenericType(params Type[])' which has 'RequiresDynamicCodeAttribute' can break functionality when AOT compiling. The native code for this instantiation might not be available at runtime. ?

I can do the actual publish and then get accurate errors, but that's quite cumbersome (proper publish takes much longer)

[MichalStrehovsky]

Could you describe more of the scenario? I assume you don't have literal if (true) in the code. In .NET 9 this will already work for things like if (RuntimeFeature.IsDynamicCodeSupported) typeof(List<>).MakeGenericType(someType); and you should not see a warning if you guard the if check using IsDynamicCodeSupported.

For the pattern you have there (typeof(List<>).MakeGenericType(typeof(bool));) - where both the definition and the instantiation argument are statically known - you should not see warning in .NET 9 even for the exact code you have there without any guards. In .NET 9, the compiler will analyze this and make sure it works with AOT.

[maumar]

I'm trying to clean up AOT warnings in the EF Core repo. The plan is to use feature switches to trim out large portion of the problematic code base (query compilation, model generation). I need to figure all the strategic places that we need to put the feature switch guard in order to trim out that code. Since feature switch effectively converts the switch property into a constant, I was hoping I could simulate what the proper feature switch + publish would do by using constant directly and rely on compiler to show me if that block would have been trimmed out. We have around 60k warnings so I'm looking for a way to get quick-and-dirty way to to see incremental progress and/or test some stuff.

I will try .net 9 and more recent VS, it should at least reduce the number of warnings that get reported and make my job bit easier, thanks.

[MichalStrehovsky]

I will try .net 9 and more recent VS, it should at least reduce the number of warnings that get reported and make my job bit easier, thanks.

.NET 9 will have more capable analysis and it also has support for feature guards that might help keep the warnings away: dotnet/designs#305. My expectation would be that you'd start with placing [RequiresUnreferencedCode]/[RequiresDynamicCode] on any classes that are not expected to be used at all and the drop down to the more granular if (SupportsQueryCompilation) checks to scope out parts of methods that could potentially call into Requires code under some circumstances.

One general warning I would give: suppressing trimming/AOT analysis warnings with UnconditionalSuppressMessages has been a bug farm even within the scope of the dotnet/runtime and dotnet/aspnetcore repos, so if you need to use that, assume it's introducing a bug unless proven otherwise (it should be reviewed with the same level of skepticism as unsafe keyword - it is not "innocent until proved guilty").

Cc @sbomer

[sbomer]

Agreed, I'd recommend you use feature guards like if (SupportsQueryCompilation). https://learn.microsoft.com/dotnet/core/whats-new/dotnet-9/runtime#attribute-model-for-feature-switches-with-trimming-support has a brief summary of the feature guard functionality. (dotnet/designs#305 discusses a somewhat broader than what was implemented for .NET 9.)

[maumar]

thanks @MichalStrehovsky and @sbomer - feel free to close the issue

[sbomer]

Thanks! Happy to help if you have any questions about feature guards/switches.