Michael Warres

Clang builds on Linux with engine=v8 actually succeed for me locally now, even though they fail in CI. One difference is that CI is using llvm-14 whereas my local build...

It would be possible to update our runners to use clang 16 instead of clang 14 by explicitly installing it in the runner as described in https://github.com/actions/runner-images/issues/8659#issuecomment-1780570741. In fact, workerd,...

> I'm back to trying to build with clang-14 + -std=c++17 for other Wasm runtimes, and -std=c++20 for v8 (as [added](https://github.com/v8/v8/blob/da4200b2cfe6eb1ad73c457ed27cf5b7ff32614f/bazel/defs.bzl#L127)) by their build rules), but am currently running into...

Rebased on top of #411

"Linux/x86_64 with GCC" failure: ``` external/v8/src/execution/isolate.h: In static member function 'static uint32_t v8::internal::Isolate::c_entry_fp_offset()': external/v8/src/execution/isolate.h:879:44: error: 'offsetof' within non-standard-layout type 'v8::internal::Isolate' is conditionally-supported [-Werror=invalid-offsetof] 879 | return static_cast(OFFSET_OF(Isolate, isolate_data_) + external/v8/src/execution/isolate.h:879:34:...

The next compilation failure, v8-specific: ``` Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging In file included from external/v8/src/compiler/turboshaft/store-store-elimination-phase.cc:5: In file...

On to the next gcc compilation error: ``` external/v8/src/ast/scopes.cc: In lambda function: external/v8/src/ast/scopes.cc:2594:25: error: implicit capture of 'this' via '[=]' is deprecated in C++20 [-Werror=deprecated] 2594 | [=](Variable* var) {...

Ok, maybe `-Wno-deprecated` wasn't it: ``` Run bazel test --verbose_failures --test_output=errors --define engine=v8 --config=gcc -- //test/... bazel test --verbose_failures --test_output=errors --define engine=v8 --config=gcc -- //test/... shell: /usr/bin/bash --noprofile --norc -e...

Obsoleted by #440

Just to understand better, is the rationale for this that the plugin already knows the context ID from on_configure, so passing it again in subsequent callbacks doesn't provide much value,...