Tweaks to warning formatting

[MichalStrehovsky]

Fixes #118788

Sample output after this change:

ILC : AOT analysis error IL1005: TestGenericLdtoken.Main(): Method in 'repro' will always throw because: Failed to load type 'F`1' from assembly 'repro, Version=10.0.0.0, Culture=neutral, PublicKey=null' because generic types cannot have explicit layout

Note that the error message is only reachable if the --resilient argument is missing. Otherwise this prints a non-error/non-warning message that already includes the assembly name

ILC : Method '[repro]TestGenericLdtoken.Main()' will always throw because: Failed to load type 'F`1' from assembly 'repro, Version=10.0.0.0, Culture=neutral, PublicKey=null' because generic types cannot have explicit layout

--resilient is passed by default and there is an undocumented opt out.

Cc @dotnet/ilc-contrib

[Copilot]

Pull Request Overview

This PR improves warning and error message formatting in the AOT compiler by adding assembly information and fixing MSBuild formatting issues. The changes address GitHub issue #118788 to provide clearer diagnostic messages when methods will always throw exceptions.

Key changes:

• Adds assembly name information to error/warning messages about methods that will always throw
• Includes extra space after "ILC" prefix to fix MSBuild formatting compatibility
• Refactors code to extract assembly name consistently for both resilient and non-resilient modes

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
RyuJitCompilation.cs	Extracts assembly name and includes it in error/warning messages for methods that always throw
MessageContainer.cs	Adds trailing space to "ILC" origin string to fix MSBuild formatting issue

---

_{You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.}

[Copilot]

[nitpick] The assembly name extraction logic uses multiple null-conditional operators in sequence, which could be simplified for better readability. Consider extracting this into a helper method or using a more explicit approach to handle the null cases.

[jkotas]

Okay I just read what it prints

What does it print? It is not obvious why we want to include the owning assembly in one message, but not the other.

[MichalStrehovsky]

Okay I just read what it prints

What does it print? It is not obvious why we want to include the owning assembly in one message, but not the other.

[repro]TestGenericLdtoken.Main() : the repro part is assembly name

[jkotas]

[repro]TestGenericLdtoken.Main() : the repro part is assembly name

Should we fix formatting that happens inside LogError to include assembly name instead, so that all uses of LogError get this improvement?