[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