refactor: c++ 17

[ShortDevelopment]

LibICU now requires c++ 17 but CC currently uses c++ 11:

ChakraCore/CMakeLists.txt

Line 375 in 36becec

set(CMAKE_CXX_STANDARD 11)

This causes MacOS ci to fail.

📣 Changes

• Upgrade catch to v1.12.2

⚠️ Deprecations

• Dynamic exception specification thow(...)
• bool std::uncaught_exception() is replaced by int uncaught_exceptions() see uncaught_exception

💥 Breaking changes

• ...

---

@ppenzin

Fixes #3147
Fixes #6378

[rhuanjl]

Is this one next up? Do you know what caused the test fails?

[ShortDevelopment]

@rhuanjl I updated the test framework used in NativeTests. I still need some time to fix this.
Could you have a look at #7042 in the meantime?

[ShortDevelopment]

We still get a test failure for x64 NativeTests which likely means GC is not working any more (not good).

ChakraCore/bin/NativeTests/JsRTApiTest.cpp

Line 136 in c6a9549

CHECK(valueRefAfterGC == JS_INVALID_REFERENCE);

So far, I cannot reproduce this issue with a local build.

Edit: The issue is reproducable using the ci build from Azure Artifacts.
The issues seems to be within ChakraCore.dll (using my local build of ChakraCore.dll fixes the issue)

Edit: Only happens in 'Test' (likely in 'Release' aswell) not 'Debug' configuration.

[rhuanjl]

We still get a test failure for x64 NativeTests which likely means GC is not working any more (not good).

ChakraCore/bin/NativeTests/JsRTApiTest.cpp

Line 136 in c6a9549

CHECK(valueRefAfterGC == JS_INVALID_REFERENCE);

So far, I cannot reproduce this issue with a local build.

Edit: The issue is reproducable using the ci build from Azure Artifacts. The issues seems to be within ChakraCore.dll (using my local build of ChakraCore.dll fixes the issue)

Edit: Only happens in 'Test' (likely in 'Release' aswell) not 'Debug' configuration.

Can you reproduce with a local Test build? Or only by downloading a test build? If this dependent on compiler versions it may be awkward to solve, hopefully it's a simple configuration issue somehow...

[ShortDevelopment]

Can you reproduce with a local Test build?

That's the problem: I can't 🙈
(I can with the x64 Test binaries from Azure Artifacts though)

If this dependent on compiler versions it may be awkward to solve

I fear that might be the case...

hopefully it's a simple configuration issue somehow...

Here's what I did:

• Download zip of this branch from github
• Unzip
• Open VS Command-Prompt (Vs 2022 v17.14.16)
• .\test\ci.buildone.cmd x64 test
• .\test\runnativetests.cmd -d true -x64 -test
• All Tests pass

[rhuanjl]

Is it necessary to specify this? I can't see that we did before.

(Also wondering if for some reason this is causing our build failure)

[ShortDevelopment]

CC on Windows uses MsBuild instead of CMake as build system. Therefore I need to set the new language standard in 2 places.

[rhuanjl]

I'm aware of the separate build system, my point was that prior to this PR whereas in cmake we specified a language standard, in msbuild we did not - unless it was set some other way I've not seen.

I was conjecturing if explicitly specifying it on the version of windows used in the CI was causing a problem.

[rhuanjl]

Looking at the diff and the failure options seem to be:

1. Somehow specifying the language standard has resulted in different behaviour - e.g. there's a C++ breaking change OR a compiler bug that we're falling into.
2. The new version of the Catch framework isn't working.
3. This is something to do with those throw(...) markers being changed to no_except; (this seems unlikely to me).

Awkwardly most of the native tests do not run on Linux/macOS so it'ss possible this problem is occurring on those platforms too (if this issue is a breaking change to C++).

[ShortDevelopment]

I used BinDiff to diff the last "working" version from ci and the ci version from this PR. The only obvious thing was the compiler inlining about 39 more methods (for win-x64).
But linux might be broken too (See #7038 (comment))

[ShortDevelopment]

I created a small test c program based on the failing native test to test the behavior on linux

• this PR: fail
• last available ci build (22f1619): fail
• last ms release (v1.11.24): pass

POC

Removing the puts line lets the test fail:

#include <string.h>
#include <stdio.h>
#include "ChakraCommon.h"
#include "ChakraCore.h"

#define REQUIRE(condition) if (!(condition)) return -1;
#define CHECK(condition) if (!(condition)) return -1;

int main(){
JsRuntimeAttributes attributes = 0;

JsRuntimeHandle runtime = JS_INVALID_RUNTIME_HANDLE;

JsValueRef context = JS_INVALID_REFERENCE;
JsValueRef setContext = JS_INVALID_REFERENCE;

// Create runtime, context and set current context
REQUIRE(JsCreateRuntime(attributes, NULL, &runtime) == JsNoError);
REQUIRE(JsCreateContext(runtime, &context) == JsNoError);
REQUIRE(JsSetCurrentContext(context) == JsNoError);
REQUIRE(((JsGetCurrentContext(&setContext) == JsNoError) || setContext == context));

JsValueRef valueRef = JS_INVALID_REFERENCE;
REQUIRE(JsCreateString("test", strlen("test"), &valueRef) == JsNoError);

JsWeakRef weakRef = JS_INVALID_REFERENCE;
REQUIRE(JsCreateWeakReference(valueRef, &weakRef) == JsNoError);

// JsGetWeakReferenceValue should return the original value reference.
JsValueRef valueRefFromWeakRef = JS_INVALID_REFERENCE;
CHECK(JsGetWeakReferenceValue(weakRef, &valueRefFromWeakRef) == JsNoError);
CHECK(valueRefFromWeakRef != JS_INVALID_REFERENCE);
CHECK(valueRefFromWeakRef == valueRef);

// Clear the references on the stack, so that the value will be GC'd.
valueRef = JS_INVALID_REFERENCE;
valueRefFromWeakRef = JS_INVALID_REFERENCE;

puts("This line is the fix?!");
CHECK(JsCollectGarbage(runtime) == JsNoError);

// JsGetWeakReferenceValue should return an invalid reference after the value was GC'd.
JsValueRef valueRefAfterGC = JS_INVALID_REFERENCE;
CHECK(JsGetWeakReferenceValue(weakRef, &valueRefAfterGC) == JsNoError);
printf("valueRefAfterGC = %ld\n", (int64_t)valueRefAfterGC);
CHECK(valueRefAfterGC == JS_INVALID_REFERENCE);

printf("Pass\n");
}