* Updates Dom lib with TSJS changes, adding a new library for webworker iterable
Co-authored-by: Nathan Shively-Sanders <nathansa@microsoft.com>
* Fixes tests
Co-authored-by: Nathan Shively-Sanders <nathansa@microsoft.com>
PR #38449 changed the second overload of the constructor for Int8,
Uint8, Int32, Uint32, Int16, Uint16, Float, Float64 -Array so that it no
longer includes `ArrayBufferLike`. It's just `ArrayLike<number>`.
This is fine except in the case that
the caller provides exactly `ArrayLike<number> | ArrayBufferLike`. This
PR adds ArrayBufferLike back so that the union is once again accepted.
This avoids a breaking change, in particular in one Microsoft-internal
codebase.
* Updates Uint8ArrayConstructor to match MDN documentation.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Uint8Array/Uint8Array
```
new Uint8Array(); // new in ES2017
new Uint8Array(length);
new Uint8Array(typedArray);
new Uint8Array(object);
new Uint8Array(buffer [, byteOffset [, length]]);
```
While the previous constructors aren't significantly different from the new, it would prevent someone from doing `new Uint8Array(myBuffer, undefined, undefined)` since there was no overload that accepted undefined as a second parameter and buffer as first.
Fixes#38446
* Fixes constructor defenition for all other typed arrays.
* Renames property to `array` since it is no longer an `arrayOrBuffer`.
* update toLocalString function signature
* update test.
* fix lint
* follow review advice.
* format and better comment.
* format
* add case
* fix symbol.
* remove subtype and string union in interface.
* remove useless code.
Co-authored-by: Song Gao <song.gao@laserfiche.com>
* Adds [unit] and [unitDisplay] to NumberFormatOptions
* Adds [unit] and [unitDisplay] to ResolvedNumberFormatOptions
* Updates tests for NumberFormatOptions and ResolvedNumberFormatOptions
* move unit[Display] from es5 to es2020
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
HTML tags in doc-comments don't get parsed properly by tools like TypeDoc,
once it encounters an open HTML tag like <b> in the comments, all the subsequent
doc-comments become bold in the generated docs.
Fixes#34931
This essentially reapplies #24436 which incorrectly updated the generated files rather than the sources, and so was wiped out by 2f73986b44a4ec10c7ebe7188e23863c3879d54e.
Note that this is specifically _not_ the same as #4002, which pertains to the global functions that coerce their arguments and therefore should _not_ accept `unknown`. This change was already accepted 18 months ago, but was applied incorrectly.
* Add the 'awaited' type operator
* Add script to manually add reviewers to a PR when GH 'Suggested Reviewers' breaks
* Fix lint error in review script
* Only defer generic awaited type for possible thenable
* Add variance-like behavior for awaited
* Switch awaited type params to 'unreliable' variance
* fix typo in inferTypes
* LKG without syntax in lib
* LKG with new syntax in lib
* Add 'strictAwaitedTypes' flag
* Treat strictAwaitedTypes as strict-mode flag
* Rename TAll, remove duplicate definition of 'race'
* Apply suggestions from code review
Co-Authored-By: ExE Boss <3889017+ExE-Boss@users.noreply.github.com>
* Fix inference priority
* Update comment to isGenericAwaitableType
* Add overloads for then/catch to Promise
* Add inference heuristic for T | PromiseLike<T> (for any PromiseLike)
* Remove strictAwaitedTypes flag
Co-authored-by: ExE Boss <3889017+ExE-Boss@users.noreply.github.com>
* make splice `deleteCount` required in es5.d.ts
In ES5 `deleteCount` is not an optional argument. If it is not provided it defaults to 0 as a side effect of `undefined` being converted to an integer.
In ES6 `deleleteCount` is optional, and it defaults to the length of the array minus the start index.
If you are targeting ES5 but don't provide `deleteCount` the behaviour will be different depending on the environment your build is running in.
fixes#32638
* update baselines
Previously subtypes of Error extended Error, but the matching subtypes
of ErrorConstructor did not extend ErrorConstructor. The members in
es5.d.ts are identical, so there's no need except for allowing interface
merging into ErrorConstructor to affect subtypes as well.
