PublishAot doesn't respect TreatWarningsAsErrors

[eerhardt]

Description

When publishing an app for AOT, and TreatWarningsAsErrors=true, if there are trim/AOT warnings, the publish doesn't fail as errors.

However, when I <PublishTrimmed>true</PublishTrimmed> the same app (with the same trimming warnings), the publish fails.

We should be consistent in our behavior between these 2 publish operations and TreatWarningsAsErrors.

Reproduction Steps

In your .csproj:

    <PublishAot>true</PublishAot>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>

And have trim warnings in your app.

Expected behavior

The publish should fail because I have warnings and TreatWarningsAsErrors=true.

Actual behavior

The trim/AOT warnings are emitted as warnings, but these warnings were not treated as errors, and my publish succeeds.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

cc @vitek-karas @agocke @MichalStrehovsky

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

When publishing an app for AOT, and TreatWarningsAsErrors=true, if there are trim/AOT warnings, the publish doesn't fail as errors.

However, when I <PublishTrimmed>true</PublishTrimmed> the same app (with the same trimming warnings), the publish fails.

We should be consistent in our behavior between these 2 publish operations and TreatWarningsAsErrors.

Reproduction Steps

In your .csproj:

    <PublishAot>true</PublishAot>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>

And have trim warnings in your app.

Expected behavior

The publish should fail because I have warnings and TreatWarningsAsErrors=true.

Actual behavior

The trim/AOT warnings are emitted as warnings, but these warnings were not treated as errors, and my publish succeeds.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

cc @vitek-karas @agocke @MichalStrehovsky

Author:	eerhardt
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[ivanpovazan]

/cc: @simonrozsival

[vitek-karas]

runtime/src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/Logger.cs

Lines 158 to 162 in 6d76479

	internal static bool IsWarningAsError(int _/*code*/)
	{
	// TODO: warnaserror
	return false;
	}

😞

This brings up an interesting behavior of MSBuild - Setting TreatWarningsAsErrors=true only applies to things which specifically react to that property, it's not a MSBuild intrinsic feature.
On the other hand passing /warnaserror on the command line to MSBuild is an intrinsic feature which makes the build fail if there are warnings. Running the repro with dotnet publish /warnaserror will actually report an error and fail the build (although it does still produce output, unlike TreatWarningsAsErrors=true which will make illink return unsucessful exit code and thus stop the build).

I do agree that we should implement this to get parity between the tools, regardless of the confusing behavior of MSBuild in this case.

[vitek-karas]

#96567 implements the same behavior as illink has, so while still not perfect (the whole discrepancy between compilers and msbuild ways of doing this), NativeAOT should now behave basically the same as the compiler and trimmer.