* Scan backticks in jsdoc as a single token less often
Previously, matching backticks in jsdoc would always be scanned as one
token to aid parsing incorrect jsdoc that uses backticks for parameter
names:
``js
/** @param {string} `nope`
* @param {number} `not needed`
*/
```
However, this is wrong for code fences, which use triple backticks. This
fix parses a single backtick as a single token if it's immediately
followed by another backtick or by a newline. It retains the
questionable tokenisation of backticks-as-pairs in other cases, however.
A better fix might be to have the parser ignore backticks in jsdoc
instead.
* Add test case
* Handle jsdoc backticks in the parser, not scanner
Previously, the jsdoc scanner had ad-hoc handling of backticks that was
similar in structure to the normal scanner's handling, but much simpler.
This was a smaller code change, but is handled backwards: the special
case of backtick-quoted parameter names was handled in the scanner
instead of in the jsdoc identifier parsing code. That made it overapply
and block correct handling of asterisks across newlines, which was most
obvious in code fences inside jsdoc, as in #23517.
Fixes#23517
* More cleanup
* Perform excess property checking on intersection and union members
* Allow partial union props to contain the undefined type
* Add test case from #30771
* Un-terse getPossiblePropertiesOfUnionType side-effecting code
* Fix bug exposed in RWC
* Cache results of getPossiblePropertiesOfUnionType
* Fix whitespace
* Use const contexts and tuple mapped types to simplify some explicitly elucidated types
* Fix lint
* Further cleanup - refactor mapped type into its own alias for readability
* Slightly more cleanup - PragmaPsuedoMap neednt be partial, thus removing tons of nonull assertions
* Remove GH#18217 comments
* Unify substitution type `any` handling into costruction and instantiation
* Strengthen supertype reduction check to reduce breakage
* Rename conditional type fields per convention
* Explicitly handle anyish signatures in compareSignaturesRelated so strict variance doesnt kill subtyping
* Allow tuple expansions to an `any` rest to be considered an `any` signature as well
* check if rest parameter is of tuple type in isOptionalParameter
* expose isArrayType and isTupleType in checker
* don't offer refactor if rest parameter type is neither array nor tuple type
* add tests for rest parameters
* fix tests for renamed refactor
* remove unnecessary conditional operator
- If composite or incremental then only the .tsbuildinfo will be generated
- if --out or --outFile the file is outputFile.tsbuildinfo
- if rootDir and outDir then outdir/relativePathOfConfigFromRootDir/configname.tsbuildinfo
- if just outDir then outDir/configname.tsbuild
- otherwise config.tsbuildinfo next to configFile
* Restore original code from bind-toplevel-this
With one or two additional comments
* Working in JS, but the symbol is not right.
Still need to
1. Make it work in Typescript.
2. Add test (and make them work) for the other uses of GlobalThis:
window, globalThis, etc.
* Check in TS also; update some tests
Lots of tests still fail, but all but 1 change so far has been correct.
* Update baselines
A couple of tests still fail and need to be fixed.
* Handle type references to globalThis
The type reference must be `typeof globalThis`. Just `globalThis` will
be treated as a value reference in type position -- an error.
* Restore former behaviour of implicitThis errors
I left the noImplicitThis rule for captured use of global this in an
arrow function, even though technically it isn't `any` any more --
it's typeof globalThis. However, you should still use some other method
to access globals inside an arrow, because captured-global-this is super
confusing there.
* Test values with type globalThis
I ran into a problem with intersecting `Window & typeof globalThis`:
1. This adds a new index signature to Window, which is probably not
desired. In fact, with noImplicitAny, it's not desired on globalThis
either I think.
2. Adding this type requires editing TSJS-lib-generator, not this repo.
So I added the test cases and will probably update them later, when
those two problems are fixed.
* Add esnext declaration for globalThis
* Switch to symbol-based approach
I decided I didn't like the import-type-based approach.
Update baselines to reflect the difference.
* Do not suggest globals for completions at toplevel
* Add tests of element and property access
* Look up globalThis using normal resolution
globalThis is no longer constructed lazily. Its synthetic Identifier
node is also now more realistic.
* Update fourslash tests
* Add missed fourslash test update
* Remove esnext.globalthis.d.ts too
* Add chained globalThis self-lookup test
* Attempt at making globalThis readonly
In progress, had to interrupt for other work.
* Add/update tests
* Addres PR comments:
1. Add parameter to tryGetThisTypeAt to exclude globalThis.
2. Use combined Module flag instead combining them in-place.
3. SymbolDisplay doesn't print 'module globalThis' for this expressions
anymore.
Sheetal Nandi
David Sherret
Andrew Branch
Nathan Shively-Sanders
Wesley Wigham
Anders Hejlsberg
Andrew Branch
Gabriela Britto
Wenlu Wang
Titian Cernicova-Dragomir
Ron Buckton
Titian Cernicova-Dragomir