Outside of JSDoc comments, postfix-? is parsed at lower precedence than the `?` of conditional types, and a postfix-? inside a tuple type results in the type being marked optional. This PR changes JSDoc parsing to behave the same way, which means that 1. Conditional types are allowed in JSDoc. Fixes #37166. 2. Tuple types' postfix-? syntax is interpreted correctly in JSDoc. Fixes #38747. The breaking change is that a postfix-? type followed by another postfix type, like `[]` or `!`, is parsed as a conditional type. [Postfix-? is not common](https://github.com/microsoft/TypeScript/issues/37166#issuecomment-612274456), so this is an acceptable breaking change. A postfix-? type `T?` is still parsed everywhere else and treated as `T | null`.
28 lines
958 B
TypeScript
28 lines
958 B
TypeScript
// @allowJs: true
|
|
// @checkJs: true
|
|
// @noEmit: true
|
|
// @strictNullChecks: true
|
|
// @noImplicitAny: true
|
|
|
|
// @Filename: prefixPostfix.js
|
|
|
|
/**
|
|
* @param {number![]} x - number[]
|
|
* @param {!number[]} y - number[]
|
|
* @param {(number[])!} z - number[]
|
|
* @param {number?[]} a - parse error without parentheses
|
|
* @param {?number[]} b - number[] | null
|
|
* @param {(number[])?} c - number[] | null
|
|
* @param {...?number} e - (number | null)[]
|
|
* @param {...number?} f - number[] | null
|
|
* @param {...number!?} g - number[] | null
|
|
* @param {...number?!} h - parse error without parentheses (also nonsensical)
|
|
* @param {...number[]} i - number[][]
|
|
* @param {...number![]?} j - number[][] | null
|
|
* @param {...number?[]!} k - parse error without parentheses
|
|
* @param {number extends number ? true : false} l - conditional types work
|
|
* @param {[number, number?]} m - [number, (number | undefined)?]
|
|
*/
|
|
function f(x, y, z, a, b, c, e, f, g, h, i, j, k, l, m) {
|
|
}
|