* Forbid accessing const & let on globalThis
It's just an error; you still get the type of the property.
* Disallow access of blockscoped vars on globalThis
Also change Array, Function, String, et al from `const` to `var` so that
they remain accessible via `globalThis.String`.
* Update baselines after lib.d.ts change
Note especially the change in redefineArray, which is now allowed as
long as you provide a type that is assignable to ArrayConstructor.
* Remove blockscoped vars from typeof globalThis
Unlike forbidding them, this removes the properties entirely.
Unfortunately, this means that accessing these properties is only an
error with noImplicitAny, and that error is quite confusing.
Let's discuss our options. I see 3:
1. Forbid access of block-scoped vars as properties (in all flag
settings), but leave them on the type. Simple to implement.
2. Remove block-scoped vars from the globalThis type. Has the bad
error/flag behaviour described above, but simple to implement.
3. Remove block-scoped vars from the globalThis type. Also, forbid
accessing them by executing another resolveName lookup for failed
property accesses on globalThisSymbol. If the second lookup returns a
blockscoped var, issue an error instead of falling back to the index
signature. This seems too complex to me.
* Update baselines
* Better error for block-scoped usage on globalThis
So that value-space references have as clear an error as type-space
references.
* Update fourslash tests
* Fix semi-colon lint
* Don't copy so much when filtering blockscoped vars
* create shorthand property assignment in argument object when possible
* add shorthand property assignment test
* don't offer refactor on jsdoc comment
* add jsdoc test
* improve jsdoc test
* use crlf
* 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
This kind of merged symbol causes crashes in two places because it's
marked BlockScoped, which makes us assume that it must be something that
is inside a SourceFile. However, block-scoped checks don't make sense
for this kind of symbol, so I exclude them by looking at the kind of
the valueDeclaration, as @mprobst suggested in the original bug.
* span on first arg that exceeds arity
* refactor baseline
* handle cases for spread arguments
* refactor + add coverage for tuple spread cases
* create diagnostic on NodeArray of exceeding args
* test function overloading
* Handle generic mapped types in getTypeOfPropertyOfContextualType.
The changes to existing baselines look acceptable to me.
Fixes#24694.
* Minor reorganization, add test case from @yortus
* Introduce simpliciations for extract/exclude-like conditional types and fix restrictive instantiations
* Add test for the common simplifications
* unify true branch constraint generation logic and true branch simplification
* Use identical check on instantiated types
* Add late-instantiate conditionals to test
* Globally cache conditional type instantiations ala indexed access types
* Handle `any` simplifications
* Factor empty intersection check into function
* Modifify conditional type constraints to better handle single-branch `any` and restrictive type parameters
* Add test case motivating prior commit
* Fix lint
* Factor logic into worker vs cacheing function
* Remove now unneeded casts
