-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Don't report dependency on canonical forms just because there's GVMs #103331
Conversation
dotnet#103039 (comment) found that we're generating some orphaned `MethodTable`s. They seem to be coming from here. Wondering if anything breaks if we just delete this.
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas |
(keeping it here for posterity, the CI results will expire at some point) |
So there are some savings with this, but nothing to write home about: Size statisticsPull request #103331
I don't know if this is worth the extra 40 lines of code. @dotnet/ilc-contrib anyone thinks this is worth it? (I would lean towards "not worth it".) |
Does this make us 100% clean wrt not generating any orphaned symbols? If it does, I would say that it is worth it. |
@ivanpovazan was #103039 (comment) the full list of symbols linker was able to strip, or just a sample? |
That was just a sample from |
UnitTest is pretty representative (it's a kitchen sink). It might be more valuable if we can not just get clean, but also stay clean. Maybe I could look if the object writer could assert that all generated symbols are also referenced, or are specified as explicit exports (e.g. UnmanagedCallersOnly entrypoints)? |
#103039 (comment) found that we're generating some orphaned
MethodTable
s. They seem to be coming from here. Wondering if anything breaks if we just delete this.