vgvassilev 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. > > For emscripten-forge recipes of xeus-cpp /clang you can break whatever you > want. I am sure there are no deployments / users yet
> > > > @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. > > For emscripten-forge recipes of xeus-cpp /clang you can break whatever you > want. I am sure there are no deployments / users yet I think Aaron's question was if we land this PR and it regresses over time, would our downstream clients be able to catch it in a timely manner. 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
