Closed kant2002 closed 2 years ago
This is boils down to patterns like this
which looks very similar to what FSharp do with printf
specialization at runtime.
I can give only indirect hint on this in form of these declarations required to make Printf works in NativeAOT
https://github.com/kant2002/RdXmlLibrary/blob/625eaf01310f2e098b8a17cfe9658e140d37262e/FSharp.Core.xml#L25-L39
I assume from the ILC
prefix that this is from NativeAOT -- moving back to the runtime repo.
Tagging subscribers to this area: @dotnet/area-extensions-configuration See info in area-owners.md if you want to be subscribed.
Author: | kant2002 |
---|---|
Assignees: | - |
Labels: | `area-Extensions-Configuration` |
Milestone: | - |
I assume this is just because the APIs haven't been annotated with RequiresDynamicCode
to bubble the requirements up to the public API, right?
I assume from the
ILC
prefix that this is from NativeAOT -- moving back to the runtime repo.
You are right. I really misinterpret results and regular trimming works fine.
I assume this is just because the APIs haven't been annotated with RequiresDynamicCode
They have been annotated with RequiresUnreferencedCode
already. Doesn't that imply that they are not safe for NativeAOT?
return config.Get
();
This API is marked as RequiresUnreferencedCode
:
Good question. So far we haven’t had RUC suppress RDC, but maybe we should @tlakollo @MichalStrehovsky
The way I see it is:
PublishTrimmed requires to be trim safe. Therefore any RequiresUnreferencedCode
attribute makes the app not safe
PublishSingleFile requires to be single file safe. Therefore any RequiresAssemblyFiles
attribute makes the app not safe
PublishAOT requires being trim, single file and dynamic code safe. Therefore any RequiresUnreferencedCode
, RequiresAssemblyFiles
, RequiresDynamicCode
make the app not safe
They have been annotated with
RequiresUnreferencedCode
already. Doesn't that imply that they are not safe for NativeAOT?
RequiresUnreferencedCode
means the result of the publishing the NativeAOT app is not safe, since trimming is not safe. Do we need to annotate also with RequiresDynamicCode
because it might also be DynamicCode? The app is not going to be safe anyway. It's already trim unsafe and making it dynamic code unsafe won't make a difference for the final NativeAOT publishing.
On the other hand the attributes are independent of the publishing type, there could be a theoretical Publishing in the future that only requires being dynamic code safe and doesn't care about trimming or single file. In that case if you didn't annotate with RequiresDynamicCode
you have a problem.
So far we haven’t had RUC suppress RDC, but maybe we should
My opinion as expresed before is that the attributes are independent, they even have different behaviors depending on the attribute (for example RequiresUnreferencedCode
interacts with Reflection and DynamicallyAccessedMembers
and the other attributes don't). They also can evolve and go completely different paths.
Also, it would be difficult to document, RUC does not suppress RAF, RDC does not suppress RUC and to be honest Im not sure RUC suppresses RDC. It kind of implies that all dynamic code is a trimming problem too, and again wouldnt hold up for a hipotetical scenario that only cares about dynamic code.
Good question. So far we haven’t had RUC suppress RDC, but maybe we should @tlakollo @MichalStrehovsky
Two comments on that. Basically +1 on what Tlaka just wrote.
double
to float
(both "primitive types") you'll run into a runtime exception. I think we'll want a RequiresDynamicCode that specifically describes the situations when MakeGeneric could be called and surface that to the user in addition to the trimming warning.It would be good to annotate these APIs for RequiresDynamicCode
in 7.0.
Consider this small application
With following packages
and `appsettings.json
ILC spill warnings
From my understanding
AppSettings
is safe to mapIConfiguration
and I want express that. But as you can see all my silly attempts fails.