Skip to content

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