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

Unknown error: Cannot read property 'declarations' of undefined #2349

Closed
1 task done
eladb opened this issue Dec 14, 2020 · 2 comments · Fixed by #2350
Closed
1 task done

Unknown error: Cannot read property 'declarations' of undefined #2349

eladb opened this issue Dec 14, 2020 · 2 comments · Fixed by #2350
Assignees
Labels
bug This issue is a bug. module/compiler Issues affecting the JSII compiler p1

Comments

@eladb
Copy link
Contributor

eladb commented Dec 14, 2020

🐛 Bug Report

Affected Languages

  • TypeScript or Javascript

General Information

  • JSII Version: 1.15.0 (build 585166b), typescript 3.9.7
  • Platform: Darwin

What is the problem?

I am not 100% sure about the circumstances of this error, but the compiler throws this error (usually when there are actual compilation issues).

Verbose Log

error JSII9997: Unknown error: Cannot read property 'declarations' of undefined -- TypeError: Cannot read property 'declarations' of undefined
    at Assembler._validateHeritageClauses (/Users/benisrae/code/cdk/aws-cdk/node_modules/jsii/lib/assembler.js:664:51)
    at Assembler._visitNode (/Users/benisrae/code/cdk/aws-cdk/node_modules/jsii/lib/assembler.js:581:18)
    at Assembler.emit (/Users/benisrae/code/cdk/aws-cdk/node_modules/jsii/lib/assembler.js:101:45)
    at async Compiler._consumeProgram (/Users/benisrae/code/cdk/aws-cdk/node_modules/jsii/lib/compiler.js:149:30)
    at async /Users/benisrae/code/cdk/aws-cdk/node_modules/jsii/bin/jsii.js:72:39

Repro

I've uploaded a zip file with the repo to here. To see the issue, run yarn build from packages/@aws-cdk/aws-secretsmanager.

@eladb eladb added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Dec 14, 2020
@RomainMuller RomainMuller self-assigned this Dec 14, 2020
@RomainMuller
Copy link
Contributor

I see - the code does not compile, so I think what is happening is the type checker inserts an "error type" which does not have an associated symbol (intentionally); which then causes this check to fail.

In such cases, we cannot rescue the failure anyway, and double-reporting it is no use... So I'll just make that code more defensive to the missing symbol.

It's also fairly tricky to reproduce because this will mostly materialise when working under --watch mode... So the type checker has a previous "good" type system to use as a crutch (so it knows where to insert what kind of "error type" as a placeholder, when things "temporarily" break)... Reproducing it (for testing purposes) is tricky because we would then need to reproduce the journey that led the compiler in that state... I will not attempt going down that road.

@RomainMuller RomainMuller added module/compiler Issues affecting the JSII compiler p1 and removed needs-triage This issue or PR still needs to be triaged. labels Dec 14, 2020
RomainMuller added a commit that referenced this issue Dec 14, 2020
When the source code does not compile due to type checking errors, the
TypeScript program model may include "error type" placeholders, to allow
the compiler to provide feedback on subsequent code. The placeholder
types do not have a symbol (quite intentionally!), and will hence cause
a failure in the `Assembler.validateHeritageClauses` method.

This change makes the code more defensive so it does not crash on this
symptom, and does not report an additional error either (the TypeScript
compiler will have done this for us already).

The bug is more likely to hit users operating under `--watch`, as the
type checker is more likely to be able to insert placeholder types in
this case, as a previous version of the program might be used as a
crutch to understand the error's context... This makes this bug
difficult to reproduce in lab conditions, and is why this change does
not include a corresponding unit test.

Fixes #2349
@mergify mergify bot closed this as completed in #2350 Dec 14, 2020
mergify bot pushed a commit that referenced this issue Dec 14, 2020
When the source code does not compile due to type checking errors, the
TypeScript program model may include "error type" placeholders, to allow
the compiler to provide feedback on subsequent code. The placeholder
types do not have a symbol (quite intentionally!), and will hence cause
a failure in the `Assembler.validateHeritageClauses` method.

This change makes the code more defensive so it does not crash on this
symptom, and does not report an additional error either (the TypeScript
compiler will have done this for us already).

The bug is more likely to hit users operating under `--watch`, as the
type checker is more likely to be able to insert placeholder types in
this case, as a previous version of the program might be used as a
crutch to understand the error's context... This makes this bug
difficult to reproduce in lab conditions, and is why this change does
not include a corresponding unit test.

Fixes #2349



---

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-actions
Copy link
Contributor

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a bug. module/compiler Issues affecting the JSII compiler p1
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants