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. 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. https://github.com/llvm/llvm-project/pull/86402 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
