ILLInk fix the usage of treatWarningsAsErrors

[SimaTian]

Describe the bug

The PR 10942 in msbuild has changed the way WarningsAsErrors are treated. Unfortunately this is incompatible with the way ILLink currenctly uses them.
We need to decide how to handle this case since the MSBuild team wants this change for the sake of consistency even though it is more breaking than expected.

To Reproduce

Enable the ILLink_can_treat_warnings_not_as_errors, ILLink_can_treat_warnings_as_errors tests within the GivenThatWeWantToRunILLink.cs test file.

[dotnet-policy-service]

@dotnet/illink a new issue has been filed in the ILLink area, please triage

[vitek-karas]

Could you please describe in more details what changed and what part is incompatible with the ILLink handling? The PR on MSBuild is not saying the details either. Maybe there's some doc which I didn't find?

[SimaTian]

We've moved the TreatWarningsAsErrors etc. to be handled via MSBuild engine directly. Not yet merged into the sdk, the PR for the update is here: .
ILLink currently uses the fact that in some cases TreatWarningsAsErrors was ignored(or more precisely not propagated) to overload the property since this PR I think.
This will cause some issues since the property /p:WarningsAsErrors=IL2075 will now be recognized by MSBuild and it will result in an error instead of warning (which was what happened up until now)

Before this change, this was an internal inconsistency within build that we were partially solving elsewhere.

[jtschuster]

I'm not sure I understand. Should the trimmer produce the warnings as warnings regardless of TreatWarningsAsErrors and WarningsAsErrors and MSBuild will report them as errors / silence them?

[vitek-karas]

Should the trimmer produce the warnings as warnings regardless of TreatWarningsAsErrors and WarningsAsErrors and MSBuild will report them as errors / silence them?

Even if that's the case, how would ILLink task know what to do - would it have to act differently based on the MSBuild version? Do we have cases like that, where tasks change their behavior based on MSBuild version?

Side note - the ILLink task behavior has been modeled by the Roslyn's behavior in this area, are we making changes to Roslyn or the Csc task related to this? Would be interesting how that was done.

[vitek-karas]

Also - ilc has some handling related to this as well. It's possible we don't have direct test coverage though - so as part of this we should also make sure that ilc works as expected.

[rainersigwald]

I do not think we should push the change here onto the ILLink task/ilc. I just think MSBuild can't make the change we wanted to make and will have to keep exposing some of the unfortunate complexity here.