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

[David Blaikie via llvm-dev]

My usual take on this would be that it's within the LLVM project norms to
fix up naming on a case by case basis (independent of the recent discussion
you mentioned) - especially if different subsets of a single
interface/group of related interfaces have become more visibly inconsistent.

On Mon, Feb 17, 2020 at 4:04 AM Ties Stuij via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200217/a6f38ab9/attachment.html>