[webkit-changes] [WebKit/WebKit] d90f93: JSValue::isConstructor is misbehaving in clang-cl ...
Ross Kirsling
noreply at github.com
Tue Oct 17 04:57:00 PDT 2023
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: d90f93a1b1854997ec227981d2e661dcc75724ad
https://github.com/WebKit/WebKit/commit/d90f93a1b1854997ec227981d2e661dcc75724ad
Author: Ross Kirsling <rkirsling at gmail.com>
Date: 2023-10-17 (Tue, 17 Oct 2023)
Changed paths:
M Source/cmake/OptionsMSVC.cmake
Log Message:
-----------
JSValue::isConstructor is misbehaving in clang-cl Release
https://bugs.webkit.org/show_bug.cgi?id=263240
Reviewed by Yusuke Suzuki.
Currently, either of the following throws a TypeError in the clang-cl Release build:
```
Reflect.construct(function () {}, [], BigInt)
Reflect.construct(function () {}, [], Symbol)
```
The cause of this is the ICF (identical code folding) link-time optimization,
which makes it unsafe to pointer-compare different functions with identical definitions.
In this particular case, constructBigIntConstructor and constructSymbol are identical to callHostFunctionAsConstructor,
so when InternalFunction::getConstructData checks whether `m_functionForConstruct == callHostFunctionAsConstructor`,
the result is erroneously true.
While this specific issue is only reproducing with clang-cl/lld-link and not normal cl/link,
we have had such issues with cl/link in the past (see 248787 at main), so let's just disable ICF altogether.
* Source/cmake/OptionsMSVC.cmake:
Canonical link: https://commits.webkit.org/269405@main
More information about the webkit-changes
mailing list