Looks like some state is not changed correctly on debugger detach, so when reattaching debugger after the profiling completes, the asm.js->js frame conversion still happens.

We probably don't need es6\es6_stable.js and friends anymore - can we remove them?

akroshg commented on Nov 30 2015
Agreed.
Should we also remove all stable flags from the .xml files?

tcare commented on Nov 30 2015
We could, but if we turn a feature off by default (e.g. due to spec change) then we would have to add them back again for that test. That has been fairly rare, so I'm ok with removing the flags.

ianwjhalliday commented on Nov 30 2015
There is still value in the idea of validating the flags so that when a new one is added we have to pay attention to its default to prevent accidentally introducing features too early. However, as we saw previously with the async feature snafu earlier, the current test does not make it obvious enough for us to catch such a mistake.

I recommend that if we spend time here changing things we should take a stab at improving the test itself after reducing it down to all that is needed.

Specific improvements I'd like to see are:

• don't use -verbose to print out the flag information; use something like -DumpEsFlags instead
  • currently this reliance on -verbose pollutes other uses of -verbose, like when looking at verbose bailout trace and dump
• get rid of -es6 and -es6all; instead introduce -esall to turn on off-by-default language features
  • perhaps also a -esexperimental to turn on all the experimental features
• beautify the flag dump information into a table showing the feature flag and its default setting (off, experimental, on)

I don't think we care about testing the semantics for specifying the switches multiple times (e.g. the -es6 -es6- test), nor do we care about seeing the current state (as opposed to the default) of each switch.

Search for IR_VIEWER macro etc in the code. Make this tool work with the ch.exe binary.

Test case

var f = arguments => arguments; // shouldn't be a syntax error
print(f(0)); // should print 0

Similar behavior for eval in place of arguments

This also affects yield. Looks like the bug is because we are treating arrow parameters as always in strict mode.

Refer duplicate OS bug 5042642

@tcare has suggested adding an auto-code-review service via chakrabot account for this type of issue rather than blocking PRs on non-functional issues.

Details:

We don't want to block builds by having an extra check for style. What we would like to have instead is an auto code-review bot that will make comments about that sort of thing, and which the author has the freedom to ignore if necessary. Not all such style changes are worth making, and it's difficult to make a good logic for style that should always be applied.

For anything that would potentially be a build-breaking check (which would require almost unanimous agreement on the team), I would prioritize like this based on likelihood of consensus:

1. Tabs
2. Trailing whitespace
3. Blank line at end of file
4. Other style (very unlikely to get unanimous approval)

We already have some necessary style checks as build-breaking checks (where necessary pertains to environment compatibility or legal requirements):

• [EOL Check] EOL characters must be checked into git as \n and not \r\n for platform compatibility.
• [Copyright Check] The Copyright header on each file must match the header required by Microsoft legal.

Labeled as "Accepting PRs" because maybe the community knows of a tool we could deploy to help us with this. It might not be a change that makes it into this repo's source but it might still be helpful.

Lowerer::Lower (Lower.cpp) doesn't generate any fast path for loading super and super constructor. It just delegates to C++ helper. Generating a simple fast path will improve the performance of jit code for constructors with super call.

       case Js::OpCode::LdSuper:
            instrPrev = m_lowererMD.LowerLdSuper(instr, IR::HelperLdSuper);
            break;

        case Js::OpCode::LdSuperCtor:
            instrPrev = m_lowererMD.LowerLdSuper(instr, IR::HelperLdSuperCtor);
            break;

Refer OS bug 5244353

When an OutOfMemory error occurred in ch.exe, the program crashed without logging an error message.

The exception in this particular case is thrown within the ArrayBuffer::ArrayBuffer constructor, but it is handled by code within ch.exe and it seems to be swallowed up without logging a message before the process dies.

The call stack that catches the OOM exception is here:

>   ChakraCore.dll!ContextAPIWrapper<0,_JsErrorCode <lambda>(Js::ScriptContext *) >(RunScriptCore::__l2::_JsErrorCode <lambda>(Js::ScriptContext *) fn) Line 155    C++
    ChakraCore.dll!RunScriptCore(const wchar_t * script, unsigned long sourceContext, const wchar_t * sourceUrl, bool parseOnly, void * * result) Line 2450 C++
    ChakraCore.dll!JsRunScript(const wchar_t * script, unsigned long sourceContext, const wchar_t * sourceUrl, void * * result) Line 2493   C++
    ch.exe!ChakraRTInterface::JsRunScript(const wchar_t * script, unsigned long sourceContext, const wchar_t * sourceUrl, void * * result) Line 178 C++
    ch.exe!RunScript(const wchar_t * fileName, const wchar_t * fileContents, unsigned char * bcBuffer, wchar_t * fullPath) Line 283 C++
    ch.exe!ExecuteTest(const wchar_t * fileName) Line 429   C++
    ch.exe!ExecuteTestWithMemoryCheck(wchar_t * fileName) Line 462  C++
    ch.exe!StaticThreadProc(void * lpParam) Line 484    C++
    ucrtbased.dll!551b8968()    Unknown
    [Frames below may be incorrect and/or missing, no symbols loaded for ucrtbased.dll] 
    ucrtbased.dll!551b867b()    Unknown
    kernel32.dll!762338f4() Unknown
    ntdll.dll!77ae56c3()    Unknown
    ntdll.dll!77ae568e()    Unknown

catch (Js::JavascriptExceptionObject *  exceptionObject)
    {
        scriptContext->GetThreadContext()->SetRecordedException(exceptionObject);
        return JsErrorScriptException;
    }

A useful error message might look like:

JavascriptError: Out of memory
        at Global code (...\path\to\blah.js:2:1)

Try running the following test case which will eventually force an OOM (on a 32-bit process):

print("hello");
var buffer = [];
for (var i = 0; ; ++i) {
    print(i);
    buffer[i] = new ArrayBuffer(1<<30);
}
print("world");

Note: on a 64-bit process you'll just end up using up all your system's memory.

At a minimum it could simply pull the current commit's metadata and report commit hash and commit date.

Array.prototype.includes (spec) is in stage 4 of ES2016 spec. This needs to be enabled by default for ChakraCore and Edge.

This built-in is currently under -ES7Builtins flag and can be enabled through experimental flag.

Note Array.prototype.includes should be added to @@unscopables (See raw TC39 notes)

Re #90, it would be nice to allow ch.exe to work with Release builds of ChakraCore.dll.

This is for general discussions on the cross-platfrom effort. Please open individual issues for tasks clearly identified from this discussion, or PRs if they are small and you can do them quickly.

Please see the Roadmap for our cross-platform checklist and progress.

Related issues:

• #197
• #198
• #200

See caitp#1 for some examples of work items we might want to consider.

Per ECMA262:
24.1.2.1ArrayBuffer( length )#

ArrayBuffer called with argument length performs the following steps:
1.If NewTarget is undefined, throw a TypeError exception.
2.Let numberLength be ? ToNumber(length).
3.Let byteLength be ToLength(numberLength).
4.If SameValueZero(numberLength, byteLength) is false, throw a RangeError exception.
5.Return ? AllocateArrayBuffer(NewTarget, byteLength).

When length == undefined, step 2 returns NaN while step 3 returns 0, therefore step 4 should throw a RangeError.

This behavior is not implemented in ChakraCore.

I was able to observe this in Edge 25.10586.0.0:

/[\ud800-\ud805]+/u.exec("\u{10000}\ud801\ud802") should return ["\ud801\ud802] but instead returns["\ud800"], which is the first half of "\u{10000}".

The spec requires the input string to be interpreted as a sequence of code points, i.e. surrogate pairs to be combined. So matching the lead surrogate of "\u{10000}" is incorrect.

A bit more reduced would be:
/\ud800+/u.exec("\u{10000}") should return null, but returns ["\ud800"] instead.

I didn't see this already so I hope it isn't a duplicate.
I also didn't see it in the roadmap.

I read the quick-start guide on embedding ChakraCore, but following this guidance will make it hard to keep an embedded version up to date.
https://github.com/Microsoft/ChakraCore/wiki/Embedding-ChakraCore

A better solution would be if MS created a NuGet package for ChakraCore and auto-published it from its build server.

Maintainers' Update

@dilijev (added 2016-04-26 / last updated 2016-01-31):

Wiki: https://github.com/Microsoft/ChakraCore/wiki/NuGet-Packages
NuGet feed: https://www.nuget.org/packages/Microsoft.ChakraCore
MyGet feed: https://www.myget.org/feed/chakracore-preview/package/nuget/Microsoft.ChakraCore

Work Items

• Use build system to create and publish daily builds as NuGet packages to MyGet.org
• Add link to MyGet feed to README and/or Wiki (@liminzhu) (#1253)
• Create a NuGet.org feed to publish our official releases (once they are available)
• When available: Add NuGet.org feed link to README and/or Wiki (@liminzhu)
• When release 1.2 is finalized: Publish ChakraCore version 1.2 to NuGet.org
• Include build number in preview package special version strings
  • Format for preview packages: Microsoft.ChakraCore.<major>.<minor>.<patch>-preview-<build1>-<build2> (e.g. Microsoft.ChakraCore.1.3.0-preview-00008-12345). Commit hash is, as always, encoded in binary metadata.
• Preview builds of multiple branches: e.g. release/* and master (Infrastructure now exists but there's no compelling reason to publish preview builds of multiple release branches -- patch updates to already-released minor versions like 1.2 and 1.3 will be extremely minor so there's nothing meaningful to preview.)
• Reorganize package layout to enable Visual C++ projects to take a dependency on native NuGet packages and automatically integrate the ChakraCore binaries into a project. (see https://docs.nuget.org/consume/support-for-native-projects) (#2266 by @pre10der89)
• NuGet package spec (nuspec) consumable by .NET projects (#2266 by @pre10der89)
• Publish preview package for .NET for validation (#85 (comment))
• Publish preview package for Native for validation (#85 (comment))
• Publish an updated NuGet package for Native projects which supports NuGet automation (as above). (See #2435)
• Publish NuGet for .NET projects. (See #2345)

Follow-up Items

Moved follow-up work items to #2578

/cc @digitalinfinity @boingoing

https://github.com/Microsoft/ChakraCore/wiki/Build-Status#legacy-builds

It seems specific to x64_debug.

While we investigate why they are timing out after 60s (despite running individually in under 10s), we will disable these tests in this configuration.

Tests I've seen affected so far:

d:\j\workspace\Private\Microsoft_ChakraCore_daily_x64_debug\test\typedarray\allocation.js
d:\j\workspace\Private\Microsoft_ChakraCore_daily_x64_debug\test\typedarray\allocation2.js
d:\j\workspace\Private\Microsoft_ChakraCore_daily_x64_debug\test\bailout\bailout7.js 
d:\j\workspace\Private\Microsoft_ChakraCore_daily_x64_debug\test\bailout\bailout-argobj.js
d:\j\workspace\Private\Microsoft_ChakraCore_daily_x64_debug\test\bailout\bailout-args.js
d:\j\workspace\Private\Microsoft_ChakraCore_daily_x64_debug\test\bailout\bailout-throw.js

Edit 3/7/16: We did not end up disabling the tests because we wanted to monitor the failures and having that build flavor green was not high priority. The problem seems to have spontaneously improved. We will monitor for a while and re-evaluate whether there is any further action to be taken on this issue.

Chakra implements LCG algorithm for Math.random. Firefox has switched to XorShift128+. Chrome used to implement MWC1616 and they have switched to xorshift128+ as well. This is a request to update Chakra Math.random implementation to use xorshift128+. Xorshift128+ is an improvement over LCG even though it still is not cryptographically secure. The same algorithm across all browsers serves well on interoperability story.

http://jandemooij.nl/blog/2015/11/30/testing-math-random-crushing-the-browser/
https://bugzilla.mozilla.org/show_bug.cgi?id=322529
http://v8project.blogspot.com/2015/12/theres-mathrandom-and-then-theres.html

Built x64_release Using Visual Studio 2015 Update 1. When running ch.exe from the command prompt it says:

Try 'ch.exe -?' for help

When issuing 'ch.exe -?', program reports error:

The binary chakracore.dll is not test enabled, please use chakracore.dll from debug/test flavor

I tried the x64-debug ch.exe to execute the following javascript code, but nothing was output. The expected output should be "Infinity".

function fact(n) {
  if (n < 2)
  {
    return 1;
  }
  else
  {
    return n * fact(n-1);
  }
}
print(fact(1000));

Add additional build tasks which will only run once per day but will test additional scenarios.

Daily task for each of [ {x86,x64,arm} x {debug,test,release} ] which are done for every commit to master and every pull request. These tasks use Windows Server 2012 R2 + VS 2015 (the default configuration of windows build machines).

Additionally, daily tasks for [ {x86,x64} x {debug,test,release} ] running on Windows 7 with VS 2013 (our earliest supported build configuration).

See table at: https://github.com/Microsoft/ChakraCore/wiki/Build-Status#disablejit-builds

Confirmed the compile error locally.

E:\dev\ChakraCore\lib\Runtime\Language\JavascriptStackWalker.h(229): error C3646: 'GetCachedInternalFrameInfo': unknown override specifier [E:\dev\ChakraCore\lib\Runtime\Base\Chakra.Runtime.Base.vcxproj]
E:\dev\ChakraCore\lib\Runtime\Language\JavascriptStackWalker.h(229): error C2059: syntax error: '(' [E:\dev\ChakraCore\lib\Runtime\Base\Chakra.Runtime.Base.vcxproj]
E:\dev\ChakraCore\lib\Runtime\Language\JavascriptStackWalker.h(229): error C2334: unexpected token(s) preceding '{'; skipping apparent function body [E:\dev\ChakraCore\lib\Runtime\Base\Chakra.Runtime.Base.vcxproj]
E:\dev\ChakraCore\lib\Runtime\Language\JavascriptStackWalker.h(330): error C3646: 'lastInternalFrameInfo': unknown override specifier [E:\dev\ChakraCore\lib\Runtime\Base\Chakra.Runtime.Base.vcxproj]
E:\dev\ChakraCore\lib\Runtime\Language\JavascriptStackWalker.h(330): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int [E:\dev\ChakraCore\lib\Runtime\Base\Chakra.Runtime.Base.vcxproj]

Looks like it might be related to c6c4de4 by @rajatd

Following should parse

var x = 10;
({x = 10} = {});

Actual: Syntax error

Refer OS bug 3887967

Many Windows applications such as AutoCAD have long embedded the Windows Script Host to allow scripting in VBScript, JavaScript, and other installed Windows Script languages, and there are a lot of system administration scripts written in JavaScript to run under WSH.

But Chakra has never been a Windows Script script engine since it was introduced in Internet Explorer 9. As a result, while IE 9-11 and Edge and now ChakraCore have leaped ahead in JavaScript support to ECMAScript 6th Edition, other Windows apps have to either adopt the new JSRT API which only came out with Chakra for IE 11, or stay stuck with JScript 5.8 and ECMAScript 3rd Edition. And adopting JSRT means either extra work to indefinitely support two embedded script subsystems, or dropping support for VBScript, perl, and other Windows Script languages.

So, I suggest the above in the title - make ChakraCore a Windows Script engine, either through internal code or a thin wrapper around JSRT that implements the IActiveScript API, and perhaps even give it the same COM ProgID as JScript 5.8 with a higher version number, so that apps can get access to Chakra when they ask for JScript.

This is big, and perhaps too big for a single work item, but I hope it can be considered nonetheless.

As per this section of ECMA spec, chakra should throw syntax error for below code, but it accepts it without errors.

(function() { "use strict"; if (true) function f() { } })()

Visiting http://dotnet-ci.cloudapp.net/job/Microsoft_ChakraCore/job/Microsoft_ChakraCore_x86_release/ or any of the other links results in a 404. Also, the images in the Build Status area are missing.

Here's my reasoning:

• switches were provided for allowing disabling unstable features for engineering infrastructure and RI
• old features are now stable and any bugs in them are not going to cause us to disable the feature
• I cannot think of any reason else why we would want to disable a given feature
• oldest switches do not necessarily even work anymore due to future changes requiring the older changes
  • e.g. let/const changed how we defer parse in a way that other features have taken a dependency on
• old unused switches are thus now useless visual cruft

Switches that I believe are reasonable to remove with no risk at this time:

• proto
• Map
• Set
• WeakMap
• ES6WeakSet
• DefineGetterSetter
• LetConst
• ES6Lambda
• ES6Math
• ES6Object
• ES6Number
• ES6String

Switches that I think are reasonable to remove but there might still be low risk in the feature having bugs or causing issues:

• ES6Iterators
• ES6NumericLiterals
• ES6Promise
• ES6StringTemplate
• ES6Symbol
• ES6Unscopables

As per exponentiation stage 3 spec -5**2 should be an early error. This is a spec update from September TC39 meeting.

See Luke Wagner's reasoning here.

"While this feature works without issue or slowdown in FF/Edge, the change-heap function interferes with the generic closure analysis that allows V8/JSC to detect and optimize the immutability of the heap view variables [11]. In V8, this causes a drastic performance penalty (see issue 39075). If that was the end of the story, I think it'd make sense to hold out until optimizations improve (e.g., on V8 is planning to do full asm.js optimizations3). However, WebAssembly will have a simpler and more direct form of resizing6 along with cross-browser support. Due to the above V8 issue, I don't think many people are using asm.js heap resizing (ALLOW_MEMORY_GROWTH is off by default in Emscripten and recommended against), so to simplify engines, I'd like to remove support for the change-heap function from SpiderMonkey and have suggested to Chakra folks that they do the same. Of course, Emscripten can still support ALLOW_MEMORY_GROWTH by simply emitting almost-but-not-asm"

I was looking over the code of conduct, out of curiousity and noticed some odd language:

We will prioritize marginalized people's safety over marginalized people's comfort.

I assume this is a typo, based on https://github.com/todogroup/opencodeofconduct/blob/gh-pages/index.md:

Our open source community prioritizes marginalized people’s safety over privileged people’s comfort.

cheers

Following test case is failing in kangax

var passed = false;
new function f() {
  passed = (new.target === f);
}();

try {
  Function("new.target = function(){};");
} catch(e) {
  return passed;
}

Tests use legacy build architecture and type terms for exclusion tags:

• exclude_amd64
• exclude_chk
• exclude_fre

test/runtests.cmd uses the new terms as input but shims them to the old terms for the exclusion tags. It would be nicer to change all the rlexe.xml files to use the new terms and remove the shim from runtests.cmd.

New tags should be:

• exclude_x64
• exclude_debug
• exclude_test

@dilijev: Update 12/18/2016

Due to the pervasive use of the old tag names across multiple dev branches and both internally and externally, the initial work item here should be to add support for the new tags, and ensure that we continue to support the old tags.

At the time of the PR which adds support, all of the existing uses of the old terms should be updated to the new terms. New tests added via other branches which do not yet support the new terms will still use the old terms, so supporting both for a time is necessary.

This means any place we would exclude either the old or new tag, we must exclude both. For example, we must exclude BOTH exclude_x64 (new) and exclude_arm64 (old), and never only one of them.

At some point in the future (when all active development branches support the new terms), we will deprecate the use of the old terms and remove support for them. At that time, all remaining uses of the old terms will be replaced with the new terms and support will be dropped from the scripts.

See follow-up work item #2240.

We are adding a bunch of new configurations with #18 and #42. With this, I'm wondering if we can include slow tests in some configuration? Right now seems like we are arbitrarily excluding a number of tests.

This is a kangax test case

function foo(){
return "𐐘".toLowerCase() === "𐑀" && "𐑀".toUpperCase() === "𐐘";
}
print(foo());

Expected: true
Actual: false

Build solutions is working great to produce ChakraCore.dll, but will there ever be an option to create a Java library so we can use this JS engine in our Java applications? Would love to see a portable version of Chakra (one that runs on OS X, Linux, etc.), similar to V8 and Mozilla's JS engines

ES spec has detailed semantics of HTML style comments.

Test case

print((function(){
--> A comment
<!-- Another comment
var a = 3; <!-- Another comment
return a === 3;
})());

Expected: true
Actual: Syntax error

这三个文件：
\lib\common\Memory\PageAllocator.h

\lib\Runtime\Library\ArgumentsObject.h

\lib\Runtime\Library\MathLibrary.cpp

warning C4819: 该文件包含不能在当前代码页(936)中表示的字符。请将该文件保存为 Unicode 格式以防止数据丢失

需要修改上述三个文件的编码才能正确编译。

ChakraCore should provide APIs to debug JavaScript

Include support for exceptions for files that should not contain the Microsoft copyright notice for various reasons (e.g. would be rendered in markdown, format of file doesn't support comments, included in this repo under a different license, etc.)

This should run as a separate Jenkins CI task from the already existing tasks to make it immediately clear what the issue is.

Also provide a script to easily fix up files that do not have the notice properly displayed.

Hi,

There's a small typo in the C++ code example at: https://github.com/Microsoft/ChakraCore/wiki/Embedding-ChakraCore

"CharkaCore.h" should be "ChakraCore.h".

Was just wondering why my VS2015 couldn't find any classes, functions etc. :)

Regards and many thanks for the Engine 👍

There is no reason for Microsoft to align itself with the institution of MIT. The ISC License is a functionally equivalent license approved by the Free Software Foundation and is compatible with Node core's license. The ISC License is the preferred license of OpenBSD, among other projects.

Except where required for performance/API reasons the c++ code should follow the C++ Core Guidelines and use the Guidelines Support Library to ensure safer code and reduce complexity and security risks

Related:C++11 Language features allowed in Chrome

Following test should should return true.

var arr = [1,2,3];
var iterableObj = {
    [Symbol.iterator]: ()=> {
        return {
            next: () => {
                return {
                    value: arr.shift(),
                    done: arr.length == 0
                };
            }
        };
    }
};
var arr = new Uint8Array(iterableObj);
print(arr);

Expected: 1,2
Actual: TypeError

See duplicate OS bug 5027123

I believe following kangax test case is dupe of this too:

(function(){
var constructors = [
  'Int8Array',
  'Uint8Array',
  'Uint8ClampedArray',
  'Int16Array',
  'Uint16Array',
  'Int32Array',
  'Uint32Array',
  'Float32Array',
  'Float64Array'
];
for(var i = 0; i < constructors.length; i++){
  var arr = new global[constructors[i]](__createIterableObject([1, 2, 3]));
  if(arr.length !== 3 || arr[0] !== 1 || arr[1] !== 2 || arr[2] !== 3)return false;
}
return true;
})();

Adapted from test262
https://github.com/tc39/test262/blob/master/test/language/statements/class/name-binding/in-extends-expression-assigned.js

var x = (class x extends x {}); // expected: ReferenceError, actual: TypeError

The error seen looks like the following:

TypeError: Function is not a constructor
        at Global code (E:\dev\debugging\class\repro.js:1:1)

Details about the expected behavior can be found in ECMAScript 2015 14.5.14.

UPDATE: See ES 2016 14.5.14 and ES 2017 14.5.13.

There is a scoping issue with the extends clause that is causing x to appear to be of an invalid type, rather than causing an error because of the attempt to reference the type which is being defined.

The following should also produce a ReferenceError when eval("x") is evaluated as the extends clause.

var x = (class x extends eval("x") {}); // expected: ReferenceError, actual: TypeError

See bug 4310932

Since Internet Explorer use Chakra, and in Internet Explorer one can new-up an ActiveXObject instance to access safe-COM objects, does that mean that this open source version of Chakra can do the same? If so, does that mean I can execute that type of code from within version of node that's bound to Chakra?

I want to be able to execute code that looks like this:
var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");

http://up-for-grabs.net/ has a curated list of tasks which are simple enough to help the community get involved in open source projects.

Refer to instructions here for how to get our repo added to the list. https://github.com/up-for-grabs/up-for-grabs.net#add-your-project

Thanks to @RichiCoder1 on Gitter for suggesting this.

This will make the contents of the root of our project more legible, and effectively bring the README into view sooner on the main page of the project.

It will require modifications to most of those scripts and to the netci.groovy script itself.

The build checks will break on the PR for this change because the Jenkins task definitions will be out of sync with the actual locations of the files, so we will need to accept the change despite the breaks and quickly react to breaks following that change.

In page https://github.com/Microsoft/ChakraCore/wiki/Building-ChakraCore, there is a typo in below step. (thtough->through)

Clone ChakraCore thtough git clone https://github.com/Microsoft/ChakraCore.git

Do you plan to implement JsVariantToValue and JsValueToVariant methods? In general, will there be added any possibility to embed custom .NET objects into JavaScript engine?

As per ES spec 22.2.4.1

We should be loading super from the current function [[prototype]] slot. Instead we always assume super is %TypedArray%. Similarly, we do not pass new.target into %TypedArray% since we do not properly call Construct abstract operation. We need some refactoring in TypedArray constructors to support this behavior.

Uint8Array.__proto__ = Math.sin
new Uint8Array(64);

Expected: TypeError
Actual: No Error

Duplicate OS bug 50260238