* Add missing currencyDisplay to resolved number format options
* Move declaration to es2020
* Update es2020.intl.d.ts
* Fix bad merge
Co-authored-by: Orta Therox <ortam@microsoft.com>
Co-authored-by: Orta Therox <git@orta.io>
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* Make Iterable Map constructor argument optional
Fixes#37779
* Change Map constructor in iterable to accept both null and undefined.
According to the spec (https://tc39.es/ecma262/#sec-map-iterable), the sole argument passed to Map is allowed to be null or undefined.
* Changed Map constructor to ensure new Map() still types as Map<any, any>.
* Add map constructor test.
This proves that the previous commit fixes#37779, as well as that new Map() still types as Map<any, any>.
* Update baseline.
Co-authored-by: Jared Neil <jaredneil@lucidchart.com>
* Allowed non-this, non-super code before super call in derived classes
Fixes#8277.
It feels wrong to put a new `forEachChild` loop in the checker, though in the vast majority of user files this will be a very quick one. Is there a better way to check for a reference to `super` or `this`?
* Used new isNewThisScope utility and dummy prop in baselines
* Accounted for parameters and get/set accessor bodies
* Accounted for class extensions
* (node|statement)RefersToSuperOrThis wasn't checking root level scope boundaries
```ts
function () {
return this;
}
```
It was immediately going to `ts.forEachChild` so the statement itself wasn't being counted as a new `this` scope.
* Better 'references' name and comments; accounted for more method edge case
* Limited super calls to root-level statements in constructor bodies
As per discussion in the issue, it would be ideal to consider any block that always ends up calling to super() the equivalent of a root-level super() statement. This would be valid:
```ts
foo = 1;
constructor() {
condition() ? super(1) : super(0);
this.foo;
}
```
...as it would compile to the equivalent of:
```ts
function () {
condition() ? super(1) : super(0);
this.foo = 1;
this.foo;
}
That change would a bit more intense and I'm very timid, so leaving it out of this PR. In the meantime the requirement is that the super() statement must itself be root-level.
* Fixed error number following 'master' merge
* Added decorator test cases
* Again allowed arrow functions
* Accepted new baselines
* Added allowance for (super())
* Reworked emitter transforms for ES this binding semantics
In trying to adjust to rbuckton's PR feedback, this orders derived class constructor bodies into five sections:
1. Pre-`super()` code
2. The `super()` call itself
3. Class properties with initializers
4. Parameter properties
5. The rest of the constructor
I've looked through the updated baselines and it looks like they're generally better than before. Within the existing test cases that result in semantic errors for `this` access before `super`, several previously resulted in a global `_this` being created; now, they correctly defer referring to `_this` until it's assigned to `_super.call(this) || this`.
* Used skipOuterExpressions when diving for super()s; fix prop ordering
* Allow direct var _this = super() when no pre-super() statements; lint fixes
* Always with the TSLint
* One last touchup: skipOuterExpressions in es2015 transformer
* Fixed new lint complaint in utilities.ts
* Again added a falls-through; it'd be swell if I could run linting locally
* This time I think I got it
* Well at least the error is a different one
* Undid irrelevant whitespace changes
* Mostly addressed private/field issues
* Accepted derivedClassSuperProperties baseline
* Lint fix, lovely
* Remove now-unnecesary comment
* First round of feedback
* Moved prologue statements to start of statements
* Added consideration for super statements in loops and the like
* Ordering and a _this_1 test
* Missed the one change I needed...
* First round of feedback corrections
* Feedback round two: statements
* Feedback: used more direct statements
* Fixed classFields emit to not duplicate temp variables
* Refactored es2015 helper to be less overloaded
* Accounted for parentheses
* Simpler feedback: -1, and emptyArray
* Next feedback: superStatementIndex
* Feedback: simplified to no longer create slice arrays
* Adjusted for default and rest parameters
* Added test case for commas
* Corrected comment ranges
* Handled comments after super, with tests
* Fixed Bad/Late super baselines
* Remove unused param and unnecessary baseline comments
Co-authored-by: Orta Therox <orta.therox@gmail.com>
Co-authored-by: Ron Buckton <ron.buckton@microsoft.com>
* Type { [P in K]: E }[X] has constraint E with X substutited for P
* Add regression test
* Fix PragmaMap and ReadonlyPragmaMap declarations
* Explore additional constraint
* Revert previous change
* Add tests
* fix(42678): detect access to uninitialized variable in IIFE
* improve performance
* Add missing space to match coding guidelines
* simplify the implementation
Co-authored-by: Jake Bailey <5341706+jakebailey@users.noreply.github.com>
* Added/updated tests.
* Accepted baselines.
* Update test.
* Update instantiateMappedType to work specially when 'any' replaced an array.
* Accepted baselines.
* Ensure check works when constraint is a union of arrayish types, just like in `Promise.all`.
* Accepted baselines.
* Update test for indirect instantiation of a mapped type.
* Accepted baselines.
* Update test comment.
* Accepted baselines.
* Added tuple test case.
* Accepted baselines.
* Don't add special behavior for tuples.
* Accepted baselines.
* Revert "Don't add special behavior for tuples."
This reverts commit f01ae16e6589ec42a931b018ffea03453df60e35.
* Accepted baselines.
* Track source and target relationship stack depth seperately, only increase on change in value
* Add baselines for test from #43485
* Bail on unwrapping conditional constraints on the source side when the source conditional is already known to be spooling out of control
* More usage of isDeeplyNestedType to block _specifically_ conditional recursion on only one side
* Negative cases of getNarrowedType that match the exact type should be filtered out, even when generic
* Add test and fix for #44404
* Swap to manually specifying left and right recursion
* Rename Left -> Source, Right -> Target
Co-authored-by: Andrew Branch <andrew@wheream.io>
* Loosen check in getIndexTypeForMappedType to directly map property names when any indexy type is present
* Handle homomorphic mappings better in keyof, add specific relationship rule for relating generic keyof MappedType to handle remapped keys
* Remove trailing whitespace