* Accept generics for defineProperty
Both `Object.defineProperty()` and `Object.defineProperties()` return their
first argument. Use a generic so that typings can be passed through.
* Update baselines
* update missed baseline
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* Eliminate well-known symbols in the checker: 2021 edition
* Actually update the lib text to say unique symbol, too (this is unneeded with compat code in place, but this makes goto-def make more sense)
* Add test showing mismatched symbol constructor type interop
* Add more test cases for some other related issues this fixes
* Revert computed name change
* Style comments
* fix: fix RelativeTimeFormat type definition
Changes:
1. Change BCP47LanguageTag to UnicodeBCP47LocaleIdentifier: Those mean 2
different things. BCP47LangTag allows _ as separator while UTS35
doesn't. It also allows grandfathered locales and UTS35 doesn't.
2. Combine RelativeTimeFormat interface and const declaration into a
single class. The old way of declaring as `interface` & `const` permits
calling `Intl.RelativeTimeFormat` without `new` which is no longer
possible after `Intl.DateTimeFormat` & `Intl.NumberFormat`. The spec
explicitly forbids it in
http://ecma-international.org/ecma-402/7.0/index.html#relativetimeformat-objects
where:
> If NewTarget is undefined, throw a TypeError exception.
Intl.RelativeTimeFormat is also extensible per spec. This is closer to a
`class` than the current declaration.
* address feedbacks
* Add definitions for WeakRef and FinalizationRegistry
Fixes#32393
* Mark callback parameter in FinalizationRegistry#cleanupSome() as optional
* Make FinalizationRegistry.prototype.cleanupSome optional
* Remove FinalizationRegistry.prototype.cleanupSome()
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* fix(lib): SharedArrayBuffer does not have a `length` field
* Revert formatting change.
* test: add tests for SharedArrayBuffer.length
Co-authored-by: Daniel Rosenwasser <DanielRosenwasser@users.noreply.github.com>
* 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.
