Eg. constructor.js was adding constructor function to aquisition.include which
resulted in the mismatch between typing installer's typeAquisition (which was passed as JSON string and parsed back to null) and one in project
That meant we kept on queuing the new typing installation request.
Fixes#27435
* Now adding @type to variable declarations, at least
Probably everything else, but not as well.
* Improve @param output and add test
It's still bad, but at least it's not wrong.
* Add some js/inferFromUsage tests and fixes
Also, remove redundant is(Set|Get)Accessor functions.
* Fix @typedef refactor
* Emit JSDoc optional parameters
By surrounding the parameter name with brackets. It is super, super ugly
right now.
* Get rest of existing tests working
* Correct location of comments
* Handle @param blocks
1. Format multiple params nicely in a single-multiline block.
2. Generate only params that haven't already been documented. Existing
documentation is not touched.
* Re-add isGet/SetAccessor -- it is part of the API
* Move isSet/GetAccessor back to the original location
* Oh no I missed a newline and a space
* Switch to an object type
* A lot of cleanup
More to come, though. annotate is only called in
annotateVariableDeclaration where we don't know whether we're in JS or
not.
* Move and delegate to annotateJSDocParameters
* Address PR comments
* Lint: newline problems!!!!
* Switch another call to getNonformattedText
* Update baseline missed after merge
The ad-hoc name resolution rule for `exports` forgets to check the
requested meaning. When `getTypeReferenceType` calls`
resolveTypeReferenceName` with `Type` only in order to give an error
when the program uses a value like a type, it is incorrectly able to
resolve `exports` instead of producing an error. Then this incorrect
symbol gets treated like an alias, which it isn't, causing the assert.
The fix, for now, is to make resolution of `exports` check the requested
meaning so that it only resolves when `Value` is requested. This makes
the above code an error ("Cannot use the namespace 'exports' as a
type."), but I think this is fine for a bug fix. We can decide later if
`exports` should behave like other expandos and be a legal type
reference.
Note that the name actually does resolve correctly, so JS users will get
the desired completions. They'll just have an error to suppress if they
have checkJs on.
The check for prototype assignment on constructor functions assumes
that the prototype property, if present, comes from an assignment
declaration, such as:
```js
SomeClass.prototype = { /* methods go here */ }
```
In this case, however, when class SomeClass and var SomeClass merge
(because this is allowed), prototype is the synthetic property from
class SomeClass, which has no valueDeclaration.
The fix is to check that prototype has a valueDeclaration before
checking whether the valueDeclaration is in fact a prototype-assignment
declaration.
`@constructor` put on anything incorrectly makes it a JS constructor. This
is a problem for actual constructors, because getJSClassType doesn't
work on actual classes. The fix is to make isJSConstructor require that
its declaration is a function.
JSDoc types references can often be to values, which can often be
circular in ways that types tied to declarations cannot. I decided to
create a separate property on SymbolLinks rather than reusing
declaredType, although I'm not sure that's strictly required.
