* Added error for class properties used within their own declaration
Fixes#5987.
Usages of a class property in a preceding property already gave an error, but the following doesn't yet:
```ts
class Test {
x: number = this.x;
}
```
As with other use-before-declare checking, IIFEs are not treated as invalid uses.
* Accepted 'witness' baselines; removed unnecessary !==
* Addressed quick feedback items
* Accepted odd new baseline
* Fixed post-merge introduced lint errors
* Updated baselines again
* Change the default type parameter constraint and default to unknown from {}
* Relax unknown checking outside of strictNullChecks a bit
* Increase strictness on index signatures with type `unknown` so inference doesnt change surprisingly
* Remove redundant switch
* 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
* add test for imported function
* start to implement import references check
* fix imported function test
* skip alias when looking for symbol target
* recognize ES6 imports
* recognize some export syntax
* add tests for imports/exports
* add test for imported function
* start to implement import references check
* fix imported function test
* skip alias when looking for symbol target
* recognize ES6 imports
* recognize some export syntax
* add tests for imports/exports
* add test for imported function
* start to implement import references check
* fix imported function test
* recognize ES6 imports
* recognize some export syntax
* add mode import/export syntax cases
* fix entryToFunctionCall to deal with new calls through property/element access expressions
* add more tests for imports/exports
* allow function and class declarations that have no name but have a default modifier
* rename tests
* fix conflict
* fix tests
* add test for nameless class
* rename function
* minor refactor
* remove old tests
* delete old test
* refactor as suggested
* use getContainingFunctionDeclaration
* 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
* 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
* Handle huge unions better in createUnionOrIntersectionProperty
* Mimic first-in-wins behavior of pushIfUnique to retain order
* !props -> props.length === 0 (why dont we warn on that ffs)
* Avoid collection into an array if there are no properties
