-
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
Another attempt at fixing #99198 #111255
Another attempt at fixing #99198 #111255
Conversation
The problem was always `// Note: We don't set the IsUnboxingStub flag on template methods (all template lookups performed at runtime are performed with this flag not set`, I tried working around it in the original fix, but looks like I actually need the function pointer in dotnet#111178 (the tests are not failing but I have a local test that does). So trying an alternative approach that just deletes the weird code. It's possible this only had to be weird due to universal shared code.
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas |
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.
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
@@ -311,11 +311,15 @@ internal void ParseNativeLayoutInfo(InstantiatedMethod method) | |||
throw new MissingTemplateException(); | |||
} | |||
|
|||
// We might have a mismatch between unboxing/non-unboxing variants so only remember it for static methods |
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.
This is my previous fix that now seems to be causing me problems.
// Note: We don't set the IsUnboxingStub flag on template methods (all template lookups performed at runtime are performed with this flag not set, | ||
// since it can't always be conveniently computed for a concrete method before looking up its template) |
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.
This is the ancient .NET Native root of all evil.
/azp run runtime-nativeaot-outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-nativeaot-outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
@davidwrighton could you have a look at this? This undoes the |
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.
I managed to chase down the initial commit which added this logic to the type loader in our old source control system, and its not clear why it was needed. If it doesn't fail the tests now, I can't see a reason to keep this weird logic around.
The problem was always
// Note: We don't set the IsUnboxingStub flag on template methods (all template lookups performed at runtime are performed with this flag not set
, I tried working around it in the original fix, but looks like I actually need the function pointer in #111178 (the tests are not failing but I have a local test that does).So trying an alternative approach that just deletes the weird code. It's possible this only had to be weird due to universal shared code.