-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Generate type generic composition information as constructed #105133
Conversation
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas |
Size statisticsPull request #105133
|
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.
Sigh
Hmm, maybe we can restrict it to types that have DAM-annotations somewhere on the generic parameters? It still fixes the DI suppression case and I can't think of other holes right now. The extra code doesn't look too terrible and I'll run rt-sz to check how much that improves things. |
Looks better like this and the code is not much more complicated: Size statisticsPull request #105133
|
/azp run runtime-nativeaot-outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
Fixes #105034.
Before this PR, whenever we had a generic instance
Foo<SomeType, OtherType<SomeOtherType>>
and we had a constructedMethodTable
for this (i.e.MethodTable
that is suitable to be used for types on the GC heap), we'd still try to optimize out theMethodTable
s forSomeType
,OtherType<SomeOtherType>
into the "unconstructed" form (i.e. without a GCDesc or vtable).This is generally a safe optimization - if
Foo<,>
actually had atypeof(T)
somewhere, we'd upgrade the unconstructed forms into constructed forms, for example.One place where the unconstructed types can be obtained is when reflection-inspecting such instantiation - asking for
GetGenericArguments
of a type could produce things that have unconstructedMethodTable
s in them. In general, this is also fine - one can't do much reflection with these and asking for e.g. names would still work fine. Trying to access members or activating something obtained fromGetGenericArguments
would trigger trimming warnings, so that's also fine.Enter Microsoft.Extension.DependencyInjection and a trimming warning suppression in there.
DI has support for something called
IOption<T>
where the T is annotated with DAM attributes. Then there's another type (OptionFactory<T>
? Can't be bothered to look at that again.) that has the T annotated the same way. Then there's some code that will deconstruct theIOption
instance that we saw statically, andMakeGenericType
anOptionFactory
with its generic arguments. The warnings on MakeGenericType are suppressed on account of: T is annotated the same, and T is not a valuetype.The suppression sounds reasonable. It just doesn't hold right now, since nothing accesses the T in IOption and we're therefore left with the unconstructed form of the T. The OptionFactory though accesses the T and tries to activate it.
This is especially a problem if IOption is instantiated over a generic type that is instantiated over a valuetype. We know we need to keep the ctor due to the annotation, but not on unconstructed forms of the type.
I was struggling with how to fix this. The easiest fix is to just stop optimizing things into unconstructed forms. This is a size regression.
Cc @dotnet/ilc-contrib