-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Put default interfaces behind a define #15358
Put default interfaces behind a define #15358
Conversation
This is needed so that we can turn default interfaces off in release branches. I can't find a central location where the PRERELEASE flag could be defined because native and managed builds seem to be completely disconnected. To limit the risk of only flipping the flag in one build type, I'm adding a test that verifies being able to load an interface with default methods matches what RuntimeFeature says.
@jkotas @weshaggard please take a look |
Cc @sergiy-k |
dir.props
Outdated
@@ -140,6 +140,10 @@ | |||
<PackageThirdPartyNoticesFile>$(ProjectDir)THIRD-PARTY-NOTICES.TXT</PackageThirdPartyNoticesFile> | |||
<SyncInfoDirectory>$(BaseIntermediateOutputPath)</SyncInfoDirectory> | |||
|
|||
<!-- If true, indicates that this is not an officially supported release --> | |||
<!-- It is important to flip this to false in official release branches --> | |||
<IsPrerelease>true</IsPrerelease> |
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.
So we need to flip both this bit and the one in clrdefinitions.cmake? Is there a good way too hook the two up together? If not can you please add a comment in both places pointing at the other so that they should be flipped together.
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 agree. Please at least add a comment.
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.
Is there a good way too hook the two up together?
I couldn't find one, but I don't know much about CoreCLR build. Is there someone who's a CoreCLR build subject matter expert who could tell us?
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.
There is not good way to link these together. The managed and unmanaged builds have to be kept in sync manually.
The flag indicates that the runtime supports default implementation of interfaces. Since this is a prerelease feature that is not complete yet (and we don't want to accidentally ship it), the flag is keyed off a newly added `IsPrerelease` property. This property is expected to be flipped to `false` in release branches. This corresponds to dotnet/coreclr#15358.
The flag indicates that the runtime supports default implementation of interfaces. Since this is a prerelease feature that is not complete yet (and we don't want to accidentally ship it), the flag is keyed off a newly added `IsPrerelease` property. This property is expected to be flipped to `false` in release branches. This corresponds to dotnet/coreclr#15358.
The flag indicates that the runtime supports default implementation of interfaces. Since this is a prerelease feature that is not complete yet (and we don't want to accidentally ship it), the flag is keyed off a newly added `IsPrerelease` property. This property is expected to be flipped to `false` in release branches. This corresponds to dotnet/coreclr#15358.
This is needed so that we can turn default interfaces off in release branches.
I can't find a central location where the PRERELEASE flag could be defined because native and managed builds seem to be completely disconnected.
To limit the risk of only flipping the flag in one build type, I'm adding a test that verifies being able to load an interface with default methods matches what RuntimeFeature says.