-
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
[CoreCLR and native AOT] UnsafeAccessorAttribute
supports generic parameters
#99468
[CoreCLR and native AOT] UnsafeAccessorAttribute
supports generic parameters
#99468
Conversation
Instance and static fields on generic types Re-enable and add to field tests
Generic types with non-generic methods.
Update tests
/azp list |
/azp run runtime-coreclr gcstress-extra |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-coreclr ilasm |
Azure Pipelines could not run because the pipeline triggers exclude this branch/path. |
UnsafeAccessorAttribute
supports generic attributesUnsafeAccessorAttribute
supports generic attributes
UnsafeAccessorAttribute
supports generic attributesUnsafeAccessorAttribute
supports generic parameters
What's the behaviour with constraints here? I assume they have to match? Asking since exposing the idea from #89439 (comment) might be interesting, either by default or with some new |
Still discussing that at present. The constraint aspect is not being addressed in this PR. Since there are a number of assumptions about using this API in general and it is considered "unsafe", it is possible it is something the user needs to ensure is correct. An official decision will be made for .NET 9 though. |
@SingleAccretion mentioned before that checking at runtime would be an additional cost for shared generics so exposing both options could be the best solution. |
/azp run runtime |
Azure Pipelines successfully started running 1 pipeline(s). |
@lambdageek Nope. I am defining "lookup" very precisely. Happy to relax this if we see compelling scenarios but I think, like the first iteration, strictness is helpful. It is for the same reason I am requiring constraints to match exactly. // also ok? - all variables, but some are rearranged
[UnsafeAccessor(UnsafeAccessorKind.Method, Name = "M")]
public extern static Tuple<U,T,V,W> CallM2<V,W>(C<U,T> c, U arg1, T arg2, V arg3, W arg4); No. They must match precisely. // also ok? - some type args are constructed types
[UnsafeAccessor(UnsafeAccessorKind.Method, Name = "M")]
public extern static Tuple<List<T>,U, V, W> CallM3<V, W>(C<List<T>, U> c, List<T> arg1, U arg2, V arg3, W arg4); No, the target signature doesn't match so lookup for // also ok? - we need to guess the method instantiation based on the arguments?
[UnsafeAccessor(UnsafeAccessorKind.Method, Name = "M")]
public extern static Tuple<T,U, V[], W[]> CallM4<V, W>(C<T, U> c, T arg1, U arg2, V[] arg3, W[] arg4); No, the target signature doesn't match so lookup for |
Add constraint test
src/tests/baseservices/compilerservices/UnsafeAccessors/UnsafeAccessorsTests.Generics.cs
Outdated
Show resolved
Hide resolved
Update tests to use unique parameter names
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.
Looks great! Thank you
We should make sure to update the docs: https://learn.microsoft.com/dotnet/api/system.runtime.compilerservices.unsafeaccessorattribute |
Yep, that is being tracked in #89439. |
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.
Support in CoreCLR and native AOT.
Contributes to #89439
The behavior expects type parameters to be supplied from a type and method generic parameters supplied from method declaration. Examples below. See also tests in PR.