-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Always show IL2026 for IsTrimmable assemblies #2087
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good but please try to run the linker on an app with for example enabled startup hook, to see if it actually works the way we think it should.
I assume the followup is to remove the detailed message origin and maybe only report an assembly, or maybe no origin if collapsing is turned on for the affected assembly. We will also probably have to change the warning message in some way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Should we use an out MessageContainer
param in TryLogSingleWarning
instead of going through LogWarning
a second time?
@vitek-karas I wasn't planning on doing this - the warning is still an IL2026 which has a documented message format, and that message doesn't make much sense without an origin - unless we wanted to give it a different warning code? Then I'm not sure what would be a good message/origin. The linker doesn't really have any more context except that the RUC method was called. Only printing the RUC user message without an origin might be a bit mysterious as to where the warning is coming from. This feels like it would be better handled by specialized warning codes for different circumstances along the lines we've been discussing. cc @eerhardt in case you have opinions on this. |
I think I'd want it to go through LogWarning again because it's kind of a separate warning. Any of the usual warning filtering should be applied - for example if there were a way to suppress assembly-level warnings, it should be possible to suppress IL2104. |
before:
after:
|
I don't think I have hugely strong opinions on it. On one hand I do like it says
so a savvy developer could go looking into our code for more information about this (comments in the code, git blame, linked issues and PRs, etc). I almost think the only real piece of that message that doesn't provide value in this case is |
Definitely a much better experience. And I would be perfectly OK shipping it this way. One day I think we should improve on this:
Ideally I think the warning should be basically: ILLink : Trim analysis warning IL2026: The StartupHookSupport feature switch has been enabled for this app which is being trimmed. Startup hook code is not observable by the trimmer and so required assemblies, types and members may be removed. http://dot.net/illink/startuphook. That is for cases where we collapse warnings. If I disable warning collapse, I should get the warning in the current form with the detailed technical description and true origin. |
This lets RUC warnings intentionally left in IsTrimmable-attributed assemblies survive collapsing, so that the user-readable message is shown.
This is a workaround for the lack of a more well-defined model for "global" warnings (such as RUC methods behind a disabled feature switch, or RUC code that's part of an override which may be called virtually). In the framework libraries we took the approach of moving
RUC
to helper methods that always have a direct callsite in managed code, and we gave the attribute a message indicating the global problem. These warnings will no longer be collapsed, but they still have a message and origin mentioning a call from non-RUC to RUC inside of the library.Addresses part of #2004.