Skip to content
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

GenAPI: Optionally wrap types in conditional compilation #10003

Merged
merged 3 commits into from
Aug 1, 2022

Conversation

akoeplinger
Copy link
Member

@akoeplinger akoeplinger commented Jul 13, 2022

This allows passing in a list of types to GenAPI that will be wrapped in #if conditional compilation blocks.

Necessary for dotnet/runtime#72143

Copy link
Member

@ericstj ericstj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feature looks good to me.
It’s not exposed from the CommandLine but perhaps that’s OK for now
no CommandLine any more

@akoeplinger akoeplinger merged commit aa90e21 into dotnet:main Aug 1, 2022
@akoeplinger akoeplinger deleted the genapi-conditional-types branch August 1, 2022 18:49
akoeplinger added a commit to dotnet/runtime that referenced this pull request Aug 2, 2022
We now compile against the reference assembly in all places where we were compiling against the mono/coreclr System.Private.CoreLib.dll implementation assembly before.

The new reference assembly consumes sources from the existing contracts to avoid checking in a generated version of SPC.dll (this would add ~20k lines of .cs which is mostly duplicated with System.Runtime.cs)

Since a few contracts have only partially moved types to SPC we wrap contract types with `#if !BUILDING_CORELIB_REFERENCE` so we can hide them when compiling the SPC reference assembly. This needed a few GenAPI changes which are implemented here: dotnet/arcade#10003.

Note that this means that the types which live in CoreLib are moved to the end of the ref .cs file which causes a GitHub diff to show up, but it is actually a no-op.

Regenerating the ref .cs files works the same way as before, by running the `GenerateReferenceAssemblySource` target in the contract's src\ folder.

Fixes #67660

Co-authored-by: Viktor Hofer <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants