AaronBallman wrote: > Following the logic in this argument, would you also say it's appropriate for > someone to commit an LLVM patch that changes how textual LLVM IR is printed > in a way that it breaks existing tests in Clang — without updating those > tests?
Possibly! I'm talking about relying on implementation details of a project and I think the textual representation of LLVM IR isn't necessarily an implementation detail of LLVM. But if the change was to an implementation detail and LLVM had a need to make the change, it's on the Clang community to react to that change. > As far as I am concerned I would expect someone making such a change to at > the very least update the Clang tests to the new format, but even better to > have a discussion with the community whether the benefits of this change > warrant the churn in the tests. I'm not trying to suggest that Clang can change anything it wants and lldb needs to just deal with it. I'm saying that Clang needs the ability to change our internal implementation details without *requiring* a PR author to update downstream projects relying on those implementation details. We should work together to reduce the amount of burden between both projects of course, but if a downstream project is expecting a very specific wording for a diagnostic message, Clang developers should not have their (correct) changes reverted because they updated the diagnostic wording and it broke a downstream test. Would it be useful for us to have a conference call to discuss this in more detail to make sure we're all clear and comfortable? 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
