fix(jsii): unable to use nested types from dependencies #1866
Conversation
When obtained through an untyped way (e.g: as part of an opaque object for example), instances of `AnonymousObject` could not be cast back to their Kernel form, because the converter lacked a code path to handle this type. Instead, it insisted on trying to infer a "better" run-time type for it. This adds the necessary code path to handle this condition and properly return the reverse conversion. Fixes aws/aws-cdk#7977
Using `--project-references`, nested types from dependencies could not be used as they would result in the following `jsii` error: ``` Type "<type name>" cannot be used as the return type because it is private or @internal ``` THis is because in `--project-references` mode, the ambient declaration for the nested type is the declaration that gets resolved to, and those cannot have the `export` keyword: instead, the surrounding module declaration is annotated with `export ambient`. This adds the necessary code path to actually identify this scenario and to appropriately detect the type is actually visible and exported. The check that was failing had been added in #1861 as a way to provide a more helpful error message when private or `@internal` types are mistakenly used on exported APIs; which explains why this situation did not previously occur.
RomainMuller
added
bug
| @@ -294,7 +293,7 @@ export class DotNetGenerator extends Generator { | |||
| this.dotnetRuntimeGenerator.emitAttributesForClass(cls); | |||
|
|
|||
| this.code.openBlock( | |||
| `public${inner}${absPrefix} class ${className}${implementsExpr}`, | |||
| `public${absPrefix} class ${className}${implementsExpr}`, | |||
There was a problem hiding this comment.
C# does not allow static member classes to declare protected members (our contract includes some, so that was bad). The presence of the static keyword here was a Java-ism, since nested classes in C# (with or without static) are actually semantically related to Java static nested classes (the syntactic sugar that Java has for non-static nested classes does not exist in C#).
There was a problem hiding this comment.
This should have been a separate PR, don'tcha agree?
There was a problem hiding this comment.
Except that separate PR's test would not have been able to pass without the other changes in this PR (cannot test I can generate a valid nested class if I can't compile it), and vice-versa (cannot check I generate valid code for a nested class if I generate invalid code for a nested class)...
How so? I need both changes in order for the test around either to pass... |
…sted-foreign-class
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Using
--project-references, nested types from dependencies could notbe used as they would result in the following
jsiierror:THis is because in
--project-referencesmode, the ambient declarationfor the nested type is the declaration that gets resolved to, and those
cannot have the
exportkeyword: instead, the surrounding moduledeclaration is annotated with
export ambient.This adds the necessary code path to actually identify this scenario and
to appropriately detect the type is actually visible and exported.
The check that was failing had been added in #1861 as a way to provide a
more helpful error message when private or
@internaltypes aremistakenly used on exported APIs; which explains why this situation did
not previously occur.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.