[wip] Update wasm exception handling model

[anutosh491]

Description

Hi,

Today while building xeus-cpp on emscripten-forge's emscripten-4x branch, I saw this

This was expected because

1. with emsdk 3.1.73 we are using the Emscripten EH model (which is pulls in the invoke_*** functions/symbols)
2. with emsdk 4-x, emscripten promotes using the wasm EH model. Hence emscripten-forge's emscripten-4x branch builds all hosted packages (xeus, llvm and everything involved using -fwasm-exceptions and -sSUPPORT_LONGJMP=wasm)
3. We need to replicate the same using clang's webassembly toolchain (https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/WebAssembly.cpp#L357-L452)

• using -fwasm-exceptions pulls in the following

-target-feature +exception-handling
-target-feature +multivalue
-target-feature +reference-types
-exception-model=wasm
-mllvm -wasm-enable-eh

• and -sSUPPORT_LONGJMP=wasm which is an emcc specific flag boils down to -mllvm -wasm-enable-sjlj which can be used through clang.

So basically we end up replicating the same result but with a different exception handling model.

Type of change

Please tick all options which are relevant.

• Bug fix
• New feature
• Added/removed dependencies
• Required documentation updates

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.94%. Comparing base (253a827) to head (91f162d).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #416   +/-   ##
=======================================
  Coverage   81.94%   81.94%           
=======================================
  Files          21       21           
  Lines         853      853           
  Branches       87       87           
=======================================
  Hits          699      699           
  Misses        154      154           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[anutosh491]

Once ready, add test

#if defined(XEUS_CPP_EMSCRIPTEN_WASM_BUILD)
    TEST_CASE("Emscripten Exception Handling")
    {
        std::vector<const char*> Args = {
            "-std=c++20",
            "-v",
            "-fwasm-exceptions",
            "-mllvm", "-wasm-enable-sjlj"
        };

        xcpp::interpreter interpreter((int)Args.size(), Args.data());
        std::string code = "try { throw 1; } catch (...) { 0; }";
        nl::json user_expressions = nl::json::object();
        xeus::execute_request_config config;
        config.silent = false;
        config.store_history = false;
        config.allow_stdin = false;
        nl::json header = nl::json::object();
        xeus::xrequest_context::guid_list id = {};
        xeus::xrequest_context context(header, id);

        std::promise<nl::json> promise;
        std::future<nl::json> future = promise.get_future();
        auto callback = [&promise](nl::json result) {
            promise.set_value(result);
        };

        interpreter.execute_request(
            std::move(context),
            std::move(callback),
            code,
            std::move(config),
            user_expressions
        );
        nl::json result = future.get();
        REQUIRE(result["status"] == "ok");
    }
#endif

We were somewhat checking the older emscripten EH model here

https://github.com/compiler-research/CppInterOp/blob/2df83a9bb4060e2bd7d2878f195eb757401405bf/unittests/CppInterOp/InterpreterTest.cpp#L164-L189

[mcbarton]

Once its ready will this PR fix this issue #412 given it involves mentions of -fwasm-exceptions ? If yes, can you link the PR to this issue, so it automatically closes with these changes.

[anutosh491]

Once its ready will this PR fix this issue #412 given it involves mentions of -fwasm-exceptions ? If yes, can you link the PR to this issue, so it automatically closes with these changes.

Well the changes above technically come in at runtime to generate correct wasm from the LLVM module. Feel free to compare the 2 wasms actually

1. deployment in the readme that's still using emsdk 3-x with emscripten EH
2. A deployment link I hosted https://anutosh491.github.io/xeus-cpp-demo/lab/index.html using emsdk 4-x with wasm EH

Compare something like to see the difference in symbols.

#include <stdexcept>

try {
    throw std::runtime_error("Unknown exception");
}
catch (const std::exception& e) {
    std::cout << "Caught an exception: " << e.what() << std::endl;
}

What you are talking about is build time stuff. So although relevant, not addressed through the above changes just yet. Let me address them though !