Skip to content

Avoid a crash with @typedef in a script file. #33847

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

Merged
merged 3 commits into from
Oct 24, 2019

Conversation

mprobst
Copy link
Contributor

@mprobst mprobst commented Oct 7, 2019

Scripts (as opposed to modules) do not have a symbol object. If a script
contains a @typdef defined on a namespace called exports, TypeScript
crashes because it attempts to create an exported symbol on the
(non-existent) symbol of the SourceFile.

This change avoids the crash by explicitly checking if the source file
has a symbol object, i.e. whether it is a module.

@mprobst mprobst changed the base branch from master to release-3.6 October 7, 2019 12:26
@mprobst
Copy link
Contributor Author

mprobst commented Oct 7, 2019

@DanielRosenwasser I'm a bit unsure whether this PR should go against release-3.6 or master. Let me know and I can re-cherry-pick/re-base, it applies cleanly against both.

@@ -491,7 +491,7 @@ namespace ts {
// and this case is specially handled. Module augmentations should only be merged with original module definition
// and should never be merged directly with other augmentation, and the latter case would be possible if automatic merge is allowed.
if (isJSDocTypeAlias(node)) Debug.assert(isInJSFile(node)); // We shouldn't add symbols for JSDoc nodes if not in a JS file.
if ((!isAmbientModule(node) && (hasExportModifier || container.flags & NodeFlags.ExportContext)) || isJSDocTypeAlias(node)) {
if ((!isAmbientModule(node) && (hasExportModifier || container.flags & NodeFlags.ExportContext)) || (isJSDocTypeAlias(node) && container.symbol)) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This avoids the crash, but I'm unsure it's the correct fix here. I'd appreciate guidance (or somebody stealing my test and fixing it properly ;-)).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a slightly different fix I'd like to push - container.symbol is undefined here because non-module files do not have an associated symbol. The root cause of the bug is attempting to bind the typedef as a module member in a non-module file. Ideally we'd not think the exports.whatever assignment is a module export assignment when the container isn't a module; but doing that's a little tough and maybe not really worth doing. Do you mind if I push my candidate change to your branch?

@DanielRosenwasser
Copy link
Member

@typescript-bot cherry-pick this to master

@DanielRosenwasser
Copy link
Member

I'm not entirely sure about the fix, but I've (hopefully) requested a cherry-pick anyway.

@typescript-bot
Copy link
Collaborator

Hey @DanielRosenwasser, I couldn't open a PR with the cherry-pick. (You can check the log here). You may need to squash and pick this PR into master manually.

@mprobst
Copy link
Contributor Author

mprobst commented Oct 7, 2019

@DanielRosenwasser bummer, didn't apply after all. Should I change this PR to be against release-3.6 or leave it like this?

@weswigham
Copy link
Member

Try retargetting the PR to master and let the bot cherry-pick to release-3.6 - I don't think it's setup to be capable of a clean squash and pick from an older release back to master, but the other way should be OK.

@mprobst mprobst changed the base branch from release-3.6 to master October 8, 2019 14:14
@typescript-bot
Copy link
Collaborator

It looks like you've sent a pull request to update our 'lib' files. These files aren't meant to be edited by hand, as they consist of last-known good states of the compiler and are generated from 'src'. Unless this is necessary, consider closing the pull request and sending a separate PR to update 'src'.

@typescript-bot typescript-bot added the lib update PR modifies files in the `lib` folder label Oct 8, 2019
@mprobst
Copy link
Contributor Author

mprobst commented Oct 8, 2019

@typescript-bot cherry-pick this to release-3.6

@mprobst
Copy link
Contributor Author

mprobst commented Oct 8, 2019

@weswigham done, though I think @typescript-bot doesn't listen to my commands (and is wrong about the lib update).

@weswigham
Copy link
Member

@typescript-bot cherry-pick this to release-3.6

typescript-bot pushed a commit to typescript-bot/TypeScript that referenced this pull request Oct 9, 2019
Component commits:
dda7cd8 Avoid a crash with `@typedef` in a script file.
Scripts (as opposed to modules) do not have a symbol object. If a script
contains a `@typdef` defined on a namespace called `exports`, TypeScript
crashes because it attempts to create an exported symbol on the
(non-existent) symbol of the SourceFile.

This change avoids the crash by explicitly checking if the source file
has a symbol object, i.e. whether it is a module.
@typescript-bot
Copy link
Collaborator

Hey @weswigham, I've opened #33888 for you.

@DanielRosenwasser DanielRosenwasser removed the lib update PR modifies files in the `lib` folder label Oct 9, 2019
@DanielRosenwasser
Copy link
Member

All good to merge @weswigham @sandersn?

Copy link
Member

@sandersn sandersn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One important question, plus @weswigham I'd like you to take a look too since you wrote the support for nameless typedefs.

/**
* @typedef {string}
*/
exports.SomeName;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a way this typedef can be used? The test should try, if only so we can see the error if it fails.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it cannot be used, see the additional commit I pushed. The typedef essentially goes ignored due to the added check for container.symbol (which is false in files that are not modules).

mprobst and others added 3 commits October 23, 2019 16:24
Scripts (as opposed to modules) do not have a symbol object. If a script
contains a `@typdef` defined on a namespace called `exports`, TypeScript
crashes because it attempts to create an exported symbol on the
(non-existent) symbol of the SourceFile.

This change avoids the crash by explicitly checking if the source file
has a symbol object, i.e. whether it is a module.
@weswigham
Copy link
Member

@sandersn would you re-review now that I've pushed a different change up, that tackles the issue closer to the source?

@weswigham weswigham requested a review from sandersn October 24, 2019 00:01
@weswigham weswigham merged commit a03227d into microsoft:master Oct 24, 2019
@weswigham
Copy link
Member

@typescript-bot cherry-pick this to release-3.7 i guess now?

@typescript-bot
Copy link
Collaborator

Hey @weswigham, I've opened #34720 for you.

typescript-bot pushed a commit to typescript-bot/TypeScript that referenced this pull request Oct 24, 2019
Component commits:
97dcbd3 Avoid a crash with `@typedef` in a script file.
Scripts (as opposed to modules) do not have a symbol object. If a script
contains a `@typdef` defined on a namespace called `exports`, TypeScript
crashes because it attempts to create an exported symbol on the
(non-existent) symbol of the SourceFile.

This change avoids the crash by explicitly checking if the source file
has a symbol object, i.e. whether it is a module.

f9b7d6e Add usage of exports.SomeName typedef.

92dc69d Fix bug at bind site rather than in declare func
DanielRosenwasser pushed a commit that referenced this pull request Oct 24, 2019
Component commits:
97dcbd3 Avoid a crash with `@typedef` in a script file.
Scripts (as opposed to modules) do not have a symbol object. If a script
contains a `@typdef` defined on a namespace called `exports`, TypeScript
crashes because it attempts to create an exported symbol on the
(non-existent) symbol of the SourceFile.

This change avoids the crash by explicitly checking if the source file
has a symbol object, i.e. whether it is a module.

f9b7d6e Add usage of exports.SomeName typedef.

92dc69d Fix bug at bind site rather than in declare func
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants