-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
[Mono] UnsafeAccessor: Support ambiguous method match #89217
[Mono] UnsafeAccessor: Support ambiguous method match #89217
Conversation
…nd address the review feedback
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.
LGTM.
My one suggestion is to move all the unsafe accessor stuff to unsafe-accessor.c
because now it doesn't depend on the loader's lookup methods.
(It would be nice to make them share, but I think this lookup stuff is kind of fragile, and if we're going to be clarifying how UnsafeAccessor
method lookup is supposed to work in .net 9, we'll have to tweak it probably, anyway. So separate file is better, I think)
Test failures are unrelated and have been reported. |
Fixes #89098
This PR adjusted Mono's method lookup behavior for UnsafeAccessor to match with CoreCLR. It conducted two rounds of lookup.
AmbiguousMatchException
.Special notes for function pointer calling convention:
If there is a single calling convention defined (i.e., Cdecl or Stdcall) then these values are not defined as custom modifiers, but instead encoded in the ECMA bits for the function pointer. They become custom modifiers, when there are more than one calling conventions defined. For example,
The corresponding IL code for methods N and M is