In JS, typedef tags are not bound on non-expression statements

[sandersn]

/** @typedef {number} A */
var ok;
/** @typedef {number} B */
ok = 1; // also ok
/** @typedef {number} C not ok */
;
/** @typedef {number} D not ok */
if (ok) {
}
/** @type {[A, B, C, D]} */
var t = [1,2,3,4]

Expected behavior:
All of A, B, C, and D are type aliases for number.

Actual behavior:
Cannot find name 'C' and 'D'.

[sandersn]

@brendankenny Since you discovered this, do you mind elaborating on your use case? Is typedef in front of (for example) an empty statement a common pattern in your code, or were you just trying to work around the typedef-end-of-file bug in #25098?

From discussing this with @mhegazy, our initial feeling is that typedefs occur almost exclusively at the beginning or end of a file, and that files usually start with a declaration or an assignment, both of which parse jsdoc. So we are looking for proof that this bug occurs commonly before starting to fix it.

[brendankenny]

our initial feeling is that typedefs occur almost exclusively at the beginning or end of a file, and that files usually start with a declaration or an assignment, both of which parse jsdoc. So we are looking for proof that this bug occurs commonly before starting to fix it.

All our typedefs that were having issues are at the end of files and are now fixed using typescript from master (looks like with #25015). Sorry, I thought I had checked master but maybe only checked typescript@next which doesn't have that commit yet.

I only ran into this issue while playing with what code could be below the typedefs and make the error go away, so while it is surprising when it happens, agreed it's a pretty unlikely problem (and a fix wouldn't help us at this point).