Skip to content

Have NativeAOT test execution project include SDK #62927

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

Merged
merged 2 commits into from
Dec 18, 2021

Conversation

MichalStrehovsky
Copy link
Member

The SDK contains logic to configure trimming - we were skipping all of that. We couldn't previously include the SDK because it would reflection-root the entrypoint assembly. No longer the case after #62890.

The SDK contains logic to configure trimming - we were skipping all of that. We couldn't previously include the SDK because it would reflection-root the entrypoint assembly. No longer the case after dotnet#62890.
@ghost
Copy link

ghost commented Dec 16, 2021

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

@ghost
Copy link

ghost commented Dec 17, 2021

Tagging subscribers to this area: @hoyosjs
See info in area-owners.md if you want to be subscribed.

Issue Details

The SDK contains logic to configure trimming - we were skipping all of that. We couldn't previously include the SDK because it would reflection-root the entrypoint assembly. No longer the case after #62890.

Author: MichalStrehovsky
Assignees: MichalStrehovsky
Labels:

area-Infrastructure-coreclr

Milestone: -

MichalStrehovsky added a commit to MichalStrehovsky/runtime that referenced this pull request Dec 17, 2021
This is now getting hit in dotnet#62927, so it's somewhat more urgent. (The feature switches from the SDK put us into the situation that triggers this bug around RunClassConstructor on an otherwise unused type.)

Fixes dotnet/runtimelab#987.

Remember what class constructor contexts we saw during scanning phase and if the owning type is also generated, assume `RunClassConstructor` could be used and ensure the cctor context is also generated in the compilation phase.

This is somewhat less precise, but introducing a new node type for "a type used with `RunClassConstructor`" that dataflow analysis could report doesn't seem worth it.
MichalStrehovsky added a commit that referenced this pull request Dec 18, 2021
This is now getting hit in #62927, so it's somewhat more urgent. (The feature switches from the SDK put us into the situation that triggers this bug around `RunClassConstructor` on an otherwise unused type.)

Fixes dotnet/runtimelab#987.

Remember what class constructor contexts we saw during scanning phase and if the owning type is also generated, assume `RunClassConstructor` could be used and ensure the cctor context is also generated in the compilation phase.

This is somewhat less precise, but introducing a new node type for "a type used with `RunClassConstructor`" that dataflow analysis could report doesn't seem worth it.
@MichalStrehovsky MichalStrehovsky merged commit 7213976 into dotnet:main Dec 18, 2021
@MichalStrehovsky MichalStrehovsky deleted the testexec branch December 19, 2021 00:04
@ghost ghost locked as resolved and limited conversation to collaborators Jan 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants