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

fix(jsii): unable to use type from dependencies' submodules #1557

Merged

Conversation

RomainMuller
Copy link
Contributor

@RomainMuller RomainMuller commented Apr 16, 2020

Commit Message

fix(jsii): unable to use type from dependencies' submodules (#1557)

When referring to a type defined in a submodule of a dependency (but
not using the "inline namespace" syntax style), the jsii compiler
failed to account for the namespace segment and generated an incorrect
fqn, leading to a type resolution error failing the compilation.

This adds a pass in the compiler to gather submodule layout from
dependencies and correctly register them in the compilation context, so
correct fqn are emitted.

New types have been introduced in @scope/jsii-calc-lib and jsii-calc
to verify that the compiler produces reasonable output. Those will be
leveraged in new compliance tests in a subsequent PR, as some
outstanding code-generation issues come in the way of these tests.

End Commit Message


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

When referring to a type defined in a submodule of a dependency (but
not using the "inline `namespace`" syntax style), the `jsii` compiler
failed to account for the namespace segment and generated an incorrect
`fqn`, leading to a type resolution error failing the compilation.

This adds a pass in the compiler to gather submodule layout from
dependencies and correctly register them in the compilation context, so
correct `fqn` are emitted.

Additionally, this highlighted an issue where namespaces defined using
the "inline `namespace`" syntax style would not be registered in the
`this._submodules` set, causing them to not always be properly
accounted for (depending on how the `TypeChecker` would represent
them).

New types have been introduced in `@scope/jsii-calc-lib` and `jsii-calc`
to verify that the compiler produces reasonable output. Those will be
leveraged in new compliance tests in a subsequent PR, as some
outstanding code-generation issues come in the way of these tests.
@RomainMuller RomainMuller self-assigned this Apr 16, 2020
@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Apr 16, 2020
@RomainMuller RomainMuller added effort/small Small work item – less than a day of effort module/compiler Issues affecting the JSII compiler labels Apr 16, 2020
@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
  • Commit ID: 95c2bf0
  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
  • Commit ID: 040557a
  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@RomainMuller
Copy link
Contributor Author

And of course the Python generated code won't load because it lacks necessary import statements, which cannot be retroactively added without knowing the list of submodules from dependencies...

RomainMuller added a commit that referenced this pull request Apr 17, 2020
Adds a `submodules` property on the `Assembly` structure, and carry it
forward in the `dependencyClosure`, so the information can later be used
to improve code generation for languages such as Python where the
submodule structure is modeled as first-class entity that needs to be
propertly dealt with. It can also help with properly adjusting the
submodule names so they look more "native" in target languages, without
facing problems when trying to generate type names in dependent packages.

The forwarding of dependent submodules is not exercized in the current
regression test suite because of a pair of other bugs (#1528, #1557)
that need to be addressed before the generated Python code can
successfully load. The last of those PRs to be merged will incldude the
necessary test coverage.
mergify bot pushed a commit that referenced this pull request Apr 20, 2020
Adds a `submodules` property on the `Assembly` structure, and carry it
forward in the `dependencyClosure`, so the information can later be used
to improve code generation for languages such as Python where the
submodule structure is modeled as first-class entity that needs to be
propertly dealt with. It can also help with properly adjusting the
submodule names so they look more "native" in target languages, without
facing problems when trying to generate type names in dependent packages.

The forwarding of dependent submodules is not exercized in the current
regression test suite because of a pair of other bugs (#1528, #1557)
that need to be addressed before the generated Python code can
successfully load. The last of those PRs to be merged will incldude the
necessary test coverage. This change is necessary for these PRs to
be able to fix their respective issues.
@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
  • Commit ID: 1c8c290
  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
  • Commit ID: 4c1d66a
  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
  • Commit ID: 62c9f53
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
  • Commit ID: a7e6c59
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify
Copy link
Contributor

mergify bot commented Apr 24, 2020

Thank you for contributing! ❤️ I will now look into making sure the PR is up-to-date, then proceed to try and merge it!

@mergify mergify bot added the pr/ready-to-merge This PR is ready to be merged. label Apr 24, 2020
@mergify mergify bot merged commit ba7fac2 into master Apr 24, 2020
@mergify mergify bot deleted the rmuller/fixup-cross-package-submodule-reference-building branch April 24, 2020 11:42
@mergify
Copy link
Contributor

mergify bot commented Apr 24, 2020

Merging (with squash)...

@mergify mergify bot removed the pr/ready-to-merge This PR is ready to be merged. label Apr 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contribution/core This is a PR that came from AWS. effort/small Small work item – less than a day of effort module/compiler Issues affecting the JSII compiler
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants