* Parse JSDoc ...T and T= only at top-level JSDoc
...T and T= should only be legal at the top level of a type, and only in
JSDoc, since at least T= is ambiguous elsewhere. This PR changes parsing
to make that happen. The resulting parse tree is now simpler, allowing
me to get rid of some code I had to add in the checker.
* Extract JSDoc type parsing into its own function
* PR comments:return from parseJSDocType
* jsdoc ?Type adds optionality to parameters
Chrome devtools expects that parameters with type `?T` (or `T?`) add
null to `T` and optionality to the parameter. Previously it only added
null to the type.
Currently the PR does *not* add undefined to the type of
`T`, which is expected by chrome-devtools-frontend, but is inconsistent
with typescript's rules. The implementation achieves this inconsistency by
exploiting the fact that checking the signature adds optionality and
checking the parameter adds `undefined`.
* Update chrome-devtools-frontend baseline
* Add optionality only for jsdoc postfix=
* Skip jsdoc prefix types in isJSDocOptionalParameter
Previously isJSDocOptionalParameter was incorrect for types like
`?number=`, which are optional but have JSDocNullableType as their root
type node.
* Refactor declaration emitter into declaration transformer
* Slight cleanup from code review feedback
* Incorporate fix for new test
* Swaths of PR feedback
* Merge public methods
* Per-file output
* Preserve input import ordering more often
* Unify jsdoc comment start detection under more lenient rule
* Move to per-file transformations to reduce the memory that msut be retained
* Fix typo
* No errr on unmatchable `@param` tags
Such as when the initializer is not a function, or when the function
mentions `arguments` in its body.
* Do not require dummy param for JS uses of arguments
1. JS functions that use `arguments` do not require a dummy parameter in
order to get a type for the synthetic `args` parameter if there is an
`@param` with a `...` type.
2.JS functions that use `arguments` and have an `@param` must have a
type that is a `...` type.
* Check for array type instead of syntactic `...`
* Address PR comments
* Update baselines
* Brackets and postfix= in `@param` add undefined
Previously they only added optionality.
Note that, unlike Typescript, when a parameter initializer is specified
in jsdoc, it does not remove undefined in the *body* of the function.
That's because TS will generate initialisation code, but JS won't, so
the author will have to manually write code to remove undefined from the
type.
```js
/** @param {number} [a=101] */
function f(a) {
// a: number | undefined here
if (!a) {
a = 101
}
// a: number here
}
```
Note that we don't check that
1. the initializer value is actually assigned to the parameter.
2. the initializer's type matches the declared type of the parameter.
Pretty much we just parse it and leave it alone.
* Address PR comments
* Harden var x=require name resolution+update chrome baseline
Chrome-devtools crashed after the new `var = require('x')` resolution
because it forgot to check whether the declaration had an initializer.
* Update chrome-devtools-frontend baseline
* Call process.stdout._handle.setBlocking(true)
This prevents output from being truncated when the compiler can output
errors to stdout faster than it can receive them. This may slow down
performance for compilations for many errors, but those were already
quite slow.
* Disable tslint no-unnnecessary-type-assertion-2
It is wrong. It *is* necessary.
* Resolve config wildcards result order in a platform independent manner
* Accept affected user test baseline
* Per reccomendation, just change matchFiles
* Add test asserting the same order on differing case sensitive platforms
1. Add documentation
2. Better organisation of concerns in utility functions
3. Better handling of module.exports and exports in the binder's new
code.
