-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
ILLink should error out when failing to resolve assemblies/types/members #103831
Comments
Tagging subscribers to this area: @agocke, @sbomer, @vitek-karas |
Last time we talked about this we noted:
While it would be nice to limit errors to the cases where trimming introduces behavior differences, I think it is not worth the complexity of correctly handling dangling references. Unity tried to do this and this was their experience:
|
@mrvoorhe last time we discussed this you mentioned:
I'm curious if you have any more insights, and whether you ended up treating forwarders specially. |
Native AOT has similar code to be able to deal with missing assembly references. We regularly get bug reports when someone tries to compile something with missing references and it hits a code path we don't handle well. I even saw at least one NuGet package that was explicitly authored to have missing dependencies (the dependency was behind a lightup). So this is purely a tradeoff between extending the funnel of "compatible-with-trimming" code and engineering improvement from not having to deal with missing references. In the native AOT compiler case, this is in a mostly leafy place (we basically just add try/catch in places that are recoverable), so I've never considered removing it. I don't know in details how pervasive it is in the illinker codebase so I can't give much of an opinion. |
@sbomer Missing forwarders in the bcl caused some pain. I didn't think about forgiving forwarder assembly resolution failures across the board like you've mentioned. What we have currently is this ugly list of assembly names not to error on if we fail to resolve them.
|
I'm OK with that change. That said, a couple thoughts. I would setup some projects that reference and use the .NET Framework shim assemblies. I had to add that We don't have UnityLinker w/ CoreCLR running in Unity yet. So I have no new data on my point of concern about how problematic
What's the motivation for changing the behavior of I don't think I've seen a case where a forwarder assembly was missing. Granted without nuget and with .NET Framework assemblies, the forwarder scene is less common. My concern is, if the goal of leaving On the other hand, if your goal of changing the behavior of |
I don't want to bring back Unresolved Stubbing to UnityLinker. And I don't really want to have to modify IL2CPP to handle unresolved types & methods. That's essentially the same game as unresolved stubbing. What can you band-aid together and deferring to a runtime exception? And what's impossible to infer enough context that you can generate C++ that will compile? I don't want to go down that road. If Microsoft wants to push the ecosystem toward not tolerating unresolved types & methods, I'm all for it. |
Currently ILLink has a relaxed default that makes a best-effort attempt to continue when it fails to resolve assemblies/types/members. This leads to bugs like #93797. We should consider making the resolution behavior stricter.
Historically, the relaxed behavior (
--skip-unresolved true
) was useful in combination with assembly-level trimming:When using aggressive trimming, I don't see any good reason for the relaxed behavior (
--skip-unresolved true
).I propose we make the following changes:
--skip-unresolved true
) strict for everything but type forwarders.--skip-unresolved false
) when usingTrimMode=link
I would make the change early in .NET 10 to give us time to respond to breaks. #91007 has additional context describing Unity's use of these options.
@vitek-karas @MichalStrehovsky @dotnet/illink
The text was updated successfully, but these errors were encountered: