[clang] [clang-repl] Support wasm execution (PR #86402)

[Aaron Ballman via cfe-commits]

AaronBallman wrote:

> > > > > @AaronBallman, to be fair, clang is testing the wasm features in terms of output. So this is wiring up a bunch of tested features that will allow execution. Clang generally does not test execution but output, so we are not creating a precedent here since that PR can be considered plumbing for downstream consumers.
> > > > 
> > > > 
> > > > If we don't have community test coverage, we'll regress that plumbing for downstream consumers. In general, we shouldn't claim we support something we don't test. However, if there is a downstream consumer that agrees to be actively responsible for repairing breakages, we sometimes allow it (e.g., https://discourse.llvm.org/t/rfc-building-llvm-for-webassembly/79073)
> > > 
> > > 
> > > I am not sure if we have the same definition for "claim". FWIW I am not saying we should put any of this on the website or elsewhere. We have a downstream consumer which intergrates the emscripten version of wasm [here](https://github.com/emscripten-forge/recipes/tree/main/recipes/recipes_emscripten/llvm). @DerThorsten is my go-to person when it comes to emscripten and llvm. I believe they are quite sensitive about breakages. In any case we will develop tests in the CppInterOp project, too.
> > 
> > 
> > I wouldn't focus on "claim" too heavily.
> 
> Ok.
> 
> > We should not have code in-tree that's not tested except in exceptional situations and it's not clear to me that this is (or isn't) such an exceptional situation.
> 
> Well, as of today I do not see how we can test execution of jit-based wasm in tree. I am not a wasm expert but IIUC, testing would require a browser and compiling llvm for emscripten and somehow running some remote execution service...

Yeah, we don't have any existing test infrastructure we could lean on for it. However, this doesn't seem impossible to test; surely other projects have figured out a test harness for WASM?

> My worry is that we are losing the forest for the trees because this work has stayed as a patch since maybe more than a year. It'd be a pity to wait more because that blocks downstream consumers in practice...

Yeah, it's a tough tradeoff. The two things I'm specifically worried about are: 1) users of the downstream see a break and (eventually) report it to Clang rather than the downstream, so now we have to triage it without a way to reproduce, 2) we change internal APIs and need to update this code but have no way to determine if those updates will or won't break the functionality.

If the downstream that needs this functionality can commit to be responsible for maintaining it within Clang, that would help alleviate the concerns somewhat.

https://github.com/llvm/llvm-project/pull/86402