Skip to content

Conversation

@sandersn
Copy link
Member

This was incorrect in the best of circumstances and caused a crash when the parent of the function had no symbol, because the accessibility check assumed it was operating on a constructor and that the parent was always the containing class.

Fixes #35766

This was incorrect in the best of circumstances and caused a crash when
the parent of the function had no symbol, because the accessibility
check assumed it was operating on a constructor and that the parent was
always the containing class.
@sandersn
Copy link
Member Author

This showed up in lodash because lodash uses @private to mean "do not export this", and therefore sticks it on almost everything in some files.

// Public constructor is accessible.
if (!modifiers) {
// (1) Public constructors and (2) constructor functions are always accessible.
if (!modifiers || isFunctionLikeDeclaration(declaration)) {
Copy link
Member Author

Choose a reason for hiding this comment

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

oops, isFunctionLikeDeclaration includes constructors. I think I'll flip the check and exclude SyntaxKind.Constructor explicitly.

Previously, all function-like kinds were accessible, which includes
constructors. This was wrong.
@sandersn sandersn merged commit 2cc1340 into master Dec 20, 2019
@sandersn sandersn deleted the ignore-private-tag-on-ctor-funcs branch December 20, 2019 16:41
@microsoft microsoft locked as resolved and limited conversation to collaborators Oct 21, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

@private on constructor function in a block causes crash

3 participants