-
Notifications
You must be signed in to change notification settings - Fork 128
Sweep EntryPoint method reference #1726
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
Conversation
|
If this is the behavior we want to codify, we need to mark https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assembly.entrypoint?view=net-5.0 as RequiresUnreferencedCode. The API is currently considered trimming safe. |
|
I'm not sure I like this - mainly due to the issue which Michal raised. Otherwise we would basically ask everybody who uses that API to suppress the warning - that's a bad experience. |
|
I think these are two separate things. The PR fixes a crash because linker keeps dangling method reference to a removed method it does not change linker behaviour regarding of Assembly.EntryPoint. Michal raised a point about Assembly.EntryPoint which today linker does not keep either and this PR does not change. We could always preserve all entry-points everywhere but we have a case in dotnet/runtime which adds I think over 10% because of duplicate entry-point and we'd need a way to opt-out from that. Another option would be to teach linker to recognize Assembly.EntryPoint reference and make the logic conditional. |
|
Thanks @marek-safar for clarification. Just curious what (roughly) is the case in dotnet/runtime which causes such a large size impact? |
|
Large is relative here, the team is working on getting each libraries tests under 2MB and we hit some unnecessary dependency in xunit runner. Thinking about the options we could also just document that if someone needs to keep entry point in "non-default" assembly they need to add it to the AssemblyRootEntryPoint items |
|
That would still not solve the annotation/warning problem - the API would still have to be annotated as dangerous. Unless we go with the intrinsic approach - what could work. |
|
Made #1729 issue about Assembly.EntryPoint API handling |
Commit migrated from dotnet/linker@7a095fa
Fixes #1713