[llvm-dev] amount of camelCase refactoring causing some downstream overhead

[Michael Kruse via llvm-dev]

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