-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[Feature request]: AOT compatibility #1732
Comments
Interesting - we did investigate this as part of #1110 and thought we were good for the v8 release (at least for all the new assemblies). We must have missed something or introduced a regression. |
Are the assemblies marked with |
The Roslyn analyzer (that gets added with Does this compile with a warning, or does it even manage to crash the compiler? |
Looks like these were the ones we already added (we tweaked them a bit for our .NET 8 branch too): Polly/src/Polly.Core/Polly.Core.csproj Lines 13 to 16 in 9b2b170
I guess we weren't aware there were additional options we needed to turn on as part of our testing. I'll take a look into this today. Assuming it's a quick fix, do you folks still have time to take a new release for the dotnet/extensions stuff for RTM? If not, we can just roll whatever fixes are needed into our 8.1.0 release which we're aiming to release once we can depend on 8.0.0 itself for support for |
The reduced issue is this: using System;
PipelineComponent p = new DelegatingComponent(null, null);
p.ExecuteCore<int, int>(state => default, default);
class PipelineComponent
{
public virtual TResult ExecuteCore<TResult, TState>(Func<TState, TResult> callback, TState state)
{
return default;
}
}
class DelegatingComponent : PipelineComponent
{
PipelineComponent _component;
PipelineComponent _next;
public DelegatingComponent(PipelineComponent component, PipelineComponent next)
{
_component = component;
_next = next;
}
public override TResult ExecuteCore<TResult, TState>(Func<TState, TResult> callback, TState state)
{
return _component.ExecuteCore(static (state) =>
{
return state._next.ExecuteCore(state.callback, state.state);
},
(_next, callback, state));
}
} Notice that More about this here: https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/warnings/il3054 Here's two samples that I know of that fixed a similar issue in different codebases: |
I'm still doing some poking around, but from doing Can you point me at a sample project somewhere I can adapt to be part of our build to use to validate native AOT support? |
Use attributes instead of pragmas so the native AOT compiler can see them. Relates to App-vNext#1732.
Where I've gotten to so far is in this branch in my fork. If I run the following it builds with no trim warnings:
|
Pasting in #1732 (comment) I can force a IL3053 warning which gives me something to iterate on for now. |
Possible fix in martincostello@393b2db#diff-ca91823ebbd702b095cfa7918b14e1504a51cb2a4125f5d7553158d1721cd80d. I'm going to benchmark it in a bit to see if the approach doesn't hurt perf. It at least fixes the |
Use attributes instead of pragmas so the native AOT compiler can see them. Relates to #1732.
Thanks for looking at this @martincostello ! |
A potential fix for App-vNext#1732 using `RuntimeFeature.IsDynamicCodeSupported` to guard against the allocation regression that avoiding the infinite generic recursion causes through boxing.
Add a benchmark for `CompositeComponent` to aid with App-vNext#1732.
Resolve two AoT warnings on `OutcomePipelineBuilderExtensions`. Relates to App-vNext#1732.
Resolve two AoT warnings on `OutcomePipelineBuilderExtensions`. Relates to App-vNext#1732.
Add a console project that validates whether the new-in-v8 Polly assemblies are AoT compatible. Relates to App-vNext#1732.
Resolve two AoT warnings on `OutcomePipelineBuilderExtensions`. Relates to #1732.
Resolve two AoT warnings on `OutcomePipelineBuilderExtensions`. Relates to #1732.
Add a benchmark for `CompositeComponent` to aid with #1732.
A potential fix for App-vNext#1732 using `RuntimeFeature.IsDynamicCodeSupported` to guard against the allocation regression that avoiding the infinite generic recursion causes through boxing.
Add a console project that validates whether the new-in-v8 Polly assemblies are AoT compatible. Relates to App-vNext#1732.
Add a console project that validates whether the new-in-v8 Polly assemblies are AoT compatible. Relates to App-vNext#1732.
A potential fix for App-vNext#1732 using `RuntimeFeature.IsDynamicCodeSupported` to guard against the allocation regression that avoiding the infinite generic recursion causes through boxing.
Add a console project that validates whether the new-in-v8 Polly assemblies are AoT compatible. Relates to App-vNext#1732.
A potential fix for App-vNext#1732 using `RuntimeFeature.IsDynamicCodeSupported` to guard against the allocation regression that avoiding the infinite generic recursion causes through boxing.
Add a console project that validates whether the new-in-v8 Polly assemblies are AoT compatible. Relates to App-vNext#1732.
A potential fix for App-vNext#1732 using `RuntimeFeature.IsDynamicCodeSupported` to guard against the allocation regression that avoiding the infinite generic recursion causes through boxing.
Add a console project that validates whether the new-in-v8 Polly assemblies are AoT compatible. Relates to App-vNext#1732.
- Fix #1732 using `RuntimeFeature.IsDynamicCodeSupported` to guard against the allocation regression that avoiding the infinite generic recursion causes through boxing. - Add a console project that validates whether the new-in-v8 Polly assemblies are AoT compatible. - Mark the new Polly v8 assemblies as AoT compatible. - Add a micro-benchmark for `DelegatingComponent` code path for non-AoT and AoT.
@davidfowl I'm planning on publishing Polly 8.1.0 release tomorrow which contains a couple of changes that should resolve your AoT warnings. If you'd like to try out a prerelease version in the meantime, there should be some NuGet packages attached to this CI build once it completes in ~30 minutes. |
Polly 8.1.0 has now been published to NuGet.org, which contains 3 different AoT fixes. |
Is your feature request related to a specific problem? Or an existing feature?
Polly is at the core of Microsoft.Extensions.Http.Resilience and we'd like the libraries that depend on this package and polly itself to work in AOT environments.
Describe the solution you'd like
Add
<IsAotCompatible>true</IsAotCompatible>
to the project files and work through the AOT issues. I've run a project that has a dependency and saw this:cc @MichalStrehovsky
Additional context
No response
The text was updated successfully, but these errors were encountered: