adrian-prantl wrote: > But also, changes in Clang that break lldb do not necessarily mean that a PR > is not ready to land. There are conforming changes that can be made to Clang > which lldb needs to react to as a downstream consumer of Clang as a library > rather than a PR author needing to react to it. (e.g., adding a new AST node > to Clang or changing diagnostic wording/behavior). We should try to come up > with and document a policy about what the expectations are regarding Clang > and lldb interactions before we add lldb to Clang's precommit CI pipeline.
I would not agree with this _specific_ wording. We have in the past and will in the future revert commits that break existing tests elsewhere in the LLVM project. If a patch to Clang breaks an existing test in LLDB, it's up to the author of the patch to work with the LLDB project members to find path forward so the patch can be merged without introducing a breakage on the bots. The specifics of that will depend on the situation (it could be supporting the feature in LLDB, changing the patch to Clang, updating an overconstrained test, XFAILing a test if there's a really good reason to do so, ...), but it's generally not okay to land a patch that breaks existing tests in the LLVM project. https://github.com/llvm/llvm-project/pull/94208 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
