feat(dotnet): update TargetFramework to net6.0 #4916
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mrgrain
changed the title
rix0rrr
approved these changes
Sep 10, 2025
Contributor
|
Thank you for contributing! ❤️ I will now look into making sure the PR is up-to-date, then proceed to try and merge it! |
Contributor
|
Merging (with squash)... |
mergify bot
pushed a commit
that referenced
this pull request
Sep 15, 2025
) This adds support for the new `class-covariant-overrides` feature into `@jsii/spec`. `class-covariant-overrides` relaxes the existing restriction on covariant overrides [^1]. With the feature it is now allowed to override the `type of readonly class properties` and the `return type of class methods` when extending other classes, as long as the changes are covariant [^2] [^3] to the superclass. Importantly, covariant overrides are still not allowed when implementing interfaces. Compilers that are producing assemblies with covariant class overrides MUST include `class-covariant-overrides` in the `usedFeatures` set. This feature does not require any changes to the kernels, runtimes or packmak. All generated code already is already correct when given an appropriate assembly. We can now add support for this feature due to the upgrade to `net6.0` [^4] which was the only thing blocking it. Proof all of this is working together: #4925 [^1]: https://aws.github.io/jsii/user-guides/lib-author/typescript-restrictions/#covariant-overrides-parameter-list-changes [^2]: https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science) [^3]: As of today this feature strictly applies to class and interface types, event though some built-in types like lists might also be technically covariant. [^4]: #4916 --- By submitting this pull request, I confirm that my contribution is made under the terms of the [Apache 2.0 license]. [Apache 2.0 license]: https://www.apache.org/licenses/LICENSE-2.0
github-merge-queue bot
pushed a commit
to aws/jsii-compiler
that referenced
this pull request
Oct 20, 2025
Relaxes the the restriction on covariant overrides as currently documented here: https://aws.github.io/jsii/user-guides/lib-author/typescript-restrictions/#covariant-overrides-parameter-list-changes Use of this new feature is indicated by the `class-covariant-overrides` feature in the produced jsii assembly. ## What is the change? It is now allowed to override the _type of readonly class properties_ and the _return type of class methods_ in class inheritance, as long as the changes are covariant to the superclass. Importantly, we still don't allow covariant overrides when implementing interfaces. ✅ now possible ```ts export class Superclass {} export class Subclass extends Superclass {} export class SomethingUnspecific { public readonly something = new Superclass(); public returnSomething(): Superclass { return new Superclass(); } } // Subclass is covariant to Superclass export class SomethingSpecific extends SomethingUnspecific { public readonly something = new Subclass(); public returnSomething(): Subclass { return new Subclass(); } } ``` ❌ still prohibited ```ts export class Superclass {} export class Subclass extends Superclass {} export interface ISomething { something: Superclass; returnSomething(): Superclass; } // ❌ covariant changes are still prohibited when implementing an interface export class SomethingImpl implements ISomething { public something: Subclass = new Subclass(); public returnSomething(): Subclass { return new Subclass(); } } ``` ## Why is this safe now? We can make these changes now, because C# 9 has added the necessary support, and this version of C# has been introduced in .NET 5. In jsii we have now made the necessary change to [increase the target framework to `net6.0`](aws/jsii#4916). C# references: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-9.0/covariant-returns https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/override https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/knowing-when-to-use-override-and-new-keywords --- By submitting this pull request, I confirm that my contribution is made under the terms of the [Apache 2.0 license]. [Apache 2.0 license]: https://www.apache.org/licenses/LICENSE-2.0
aws-cdk-automation
pushed a commit
to aws/jsii-compiler
that referenced
this pull request
Oct 29, 2025
Relaxes the the restriction on covariant overrides as currently documented here: https://aws.github.io/jsii/user-guides/lib-author/typescript-restrictions/#covariant-overrides-parameter-list-changes Use of this new feature is indicated by the `class-covariant-overrides` feature in the produced jsii assembly. ## What is the change? It is now allowed to override the _type of readonly class properties_ and the _return type of class methods_ in class inheritance, as long as the changes are covariant to the superclass. Importantly, we still don't allow covariant overrides when implementing interfaces. ✅ now possible ```ts export class Superclass {} export class Subclass extends Superclass {} export class SomethingUnspecific { public readonly something = new Superclass(); public returnSomething(): Superclass { return new Superclass(); } } // Subclass is covariant to Superclass export class SomethingSpecific extends SomethingUnspecific { public readonly something = new Subclass(); public returnSomething(): Subclass { return new Subclass(); } } ``` ❌ still prohibited ```ts export class Superclass {} export class Subclass extends Superclass {} export interface ISomething { something: Superclass; returnSomething(): Superclass; } // ❌ covariant changes are still prohibited when implementing an interface export class SomethingImpl implements ISomething { public something: Subclass = new Subclass(); public returnSomething(): Subclass { return new Subclass(); } } ``` ## Why is this safe now? We can make these changes now, because C# 9 has added the necessary support, and this version of C# has been introduced in .NET 5. In jsii we have now made the necessary change to [increase the target framework to `net6.0`](aws/jsii#4916). C# references: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-9.0/covariant-returns https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/override https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/knowing-when-to-use-override-and-new-keywords --- By submitting this pull request, I confirm that my contribution is made under the terms of the [Apache 2.0 license]. [Apache 2.0 license]: https://www.apache.org/licenses/LICENSE-2.0 (cherry picked from commit 0e9cf43)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
.NET Core 3.1 has been EOL for a while now [1]
We have for a long time stop testing for it and have advertised .NET 6 as minimum requirement. [2]
This was previously attempted in #3957 and reverted in #3987. It's not obvious to me anymore what exactly caused the decision to revert the change.
I believe the lack of the
RollForwarddirective would have previously prevented the use of packages created with an olderjsii-pacmakversion together with packages created by a newer version. SinceRollForwardhas no been established, we can attempt this again. If anything I will now aim to resolve any emergent issues and/or document possible failures better.Closes #4574
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.