[llvm-dev] amount of camelCase refactoring causing some downstream overhead (original) (raw)

Ties Stuij via llvm-dev llvm-dev at lists.llvm.org
Tue Feb 18 01:37:29 PST 2020

During that variable renaming debate, there was a discussion about discussion about doing things all at once, piecemeal or not at all. An issue that wasn't really resolved I think. I had the impression that the efforts fizzled out a bit, and I thought this renaming was maybe related to that, but I'm neutral on if we should do variable renaming.

All I'm asking as a kindness if we could be kind on poor downstream maintainers not on the issue of variable renaming at large, but on the micro level of not pushing 5/6 patches of this kind covering closely related functionality in two days but collating them in 1. I don't think that would slow down development, and I wanted to highlight the issue, as people might not be aware that they could save some pain in a simple way. Especially if indeed there is going to be a big renaming push and this would be a continuous thing.

Cheers, /Ties

From: Michael Kruse <llvmdev at meinersbur.de> Sent: 17 February 2020 21:16 To: Ties Stuij Cc: llvm-dev Subject: Re: [llvm-dev] amount of camelCase refactoring causing some downstream overhead

My understanding is that LLVM's general policy is to not let downstream slow down upstream development. The C++ API explicitly unstable.

Note that we are even considering renaming variables globally: https://lists.llvm.org/pipermail/llvm-dev/2019-September/134921.html

Michael

Am Mo., 17. Feb. 2020 um 06:04 Uhr schrieb Ties Stuij via llvm-dev <llvm-dev at lists.llvm.org>:

Hi there, At the end of last week we saw a number of commits go in that were camelCasing batches of MCStreamer::Emit* and AsmPrinter::Emit* functions. For example: - https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691 - https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b - https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956 Unfortunately all these individual commits trigger the same merge conflicts over and over again with our downstream repo, which takes us some manual intervention every time. I understand uniformity is a nice to have, but: 1 - is it worth it to do this work right now? I can remember the casing debate a few months back, which seems unrelated to this work which seems manual, but I'm unsure of the outcome. 2 - If this work should be done, it would be nice if all of the work is done in one batch, to save us some of the downstream overhead. Thanks /Ties

LLVM Developers mailing list llvm-dev at lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

More information about the llvm-dev mailing list