[webkit-changes] [WebKit/WebKit] 41d744: [GTK][WPE] `TestJSC` `/jsc/basic` API test is flaky

[Vitaly Dyachkov]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 41d744be940c32814bcfc1740dcca8dfd3c38837
      https://github.com/WebKit/WebKit/commit/41d744be940c32814bcfc1740dcca8dfd3c38837
  Author: Vitaly Dyachkov <vitaly at igalia.com>
  Date:   2023-07-13 (Thu, 13 Jul 2023)

  Changed paths:
    M Tools/TestWebKitAPI/Tests/JavaScriptCore/glib/TestJSC.cpp

  Log Message:
  -----------
  [GTK][WPE] `TestJSC` `/jsc/basic` API test is flaky
https://bugs.webkit.org/show_bug.cgi?id=259178

Reviewed by Michael Catanzaro.

On WPE and GTK, when we evaluate a JS expression, we wrap the resulting
`JSValueRef` in `JSCValue`.

Internally, we cache and reuse a `JSValue` for expressions that evaluate
to the same `JSValueRef` result.

When `JSCValue` object is destroyed it is also removed from the cache.

There is a test in `testJSCBasic()` which checks that after we destroy
a `JSCValue` and then evaluate the same JS expression, a new `JSCValue`
wrapper is created:

```
GRefPtr<JSCValue> result = adoptGRef(jsc_context_evaluate(context.get(), "2 + 2", -1));
auto* resultPtr = result.get();
result = nullptr;
GRefPtr<JSCValue> result4 = adoptGRef(jsc_context_evaluate(context.get(), "2 + 2", -1));
g_assert_false(result4.get() == resultPtr);
```

To verify that we got a new object we simply compare memory addresses.
But it might happen (and actually happens on bots) that the new wrapper
is allocated at the same address as the original one, making this test fail.

What we can do instead, is to tag the original `JSCValue` and then
ensure that the new `JSCValue` is not tagged.

* Tools/TestWebKitAPI/Tests/JavaScriptCore/glib/TestJSC.cpp:
(testJSCBasic):

Canonical link: https://commits.webkit.org/266035@main