refactor: c++ 17 #7038
refactor: c++ 17 #7038
Conversation
ShortDevelopment
changed the title
ShortDevelopment
force-pushed
the
feature/cpp-17
branch
from
bbfda98 to
3576eb9
Compare
|
Is this one next up? Do you know what caused the test fails? |
ShortDevelopment
force-pushed
the
feature/cpp-17
branch
from
3576eb9 to
0dd3516
Compare
ShortDevelopment
force-pushed
the
feature/cpp-17
branch
from
0dd3516 to
cd81a22
Compare
| #elif defined(_M_ARM) | ||
| extern "C" void *arm_CallEhFrame(void *target, void *framePtr, void *localsPtr, size_t argsSize) throw(...); | ||
| extern "C" void *arm_CallCatch(void *target, void *framePtr, void *localsPtr, size_t argsSize, void *catchObj) throw(...); | ||
| extern "C" void *arm_CallEhFrame(void *target, void *framePtr, void *localsPtr, size_t argsSize); |
There was a problem hiding this comment.
Should there be a noexcept(false) on this line, like the other lines?
There was a problem hiding this comment.
Oh, yes. Seems like I missed that one.
Interestingly, none of the CI compilations got that...
There was a problem hiding this comment.
32bit arm is a gap in our testing coverage; when we set up the CI we couldn't find a free service that would test it for us.
There was a problem hiding this comment.
Fixed in 6bf3471
|
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 So far, I cannot reproduce this issue with a local build. Edit: The issue is reproducable using the ci build from Azure Artifacts. Edit: Only happens in 'Test' (likely in 'Release' aswell) not 'Debug' configuration. |
ShortDevelopment
force-pushed
the
feature/cpp-17
branch
from
d2fdef9 to
b8e02b3
Compare
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... |
That's the problem: I can't 🙈
I fear that might be the case...
Here's what I did:
|
| <PreprocessorDefinitions Condition="'$(ChakraVersionBuildDate)'!=''">%(PreprocessorDefinitions);CHAKRA_VERSION_BUILD_DATE=$(ChakraVersionBuildDate)</PreprocessorDefinitions> | ||
|
|
||
|
|
||
| <LanguageStandard>stdcpp17</LanguageStandard> |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
CC on Windows uses MsBuild instead of CMake as build system. Therefore I need to set the new language standard in 2 places.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Looking at the diff and the failure options seem to be:
- 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.
- The new version of the Catch framework isn't working.
- 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++).
2 participants
LibICU now requires c++ 17 but CC currently uses c++ 11:
ChakraCore/CMakeLists.txt
Line 375 in 36becec
This causes MacOS ci to fail.
📣 Changes
thow(...)bool std::uncaught_exception()is replaced byint uncaught_exceptions()see uncaught_exception💥 Breaking changes
@ppenzin
Fixes #3147
Fixes #6378