r176428 - Perform non-overload placeholder conversions on the operands

[Richard Smith]

On Fri, Mar 8, 2013 at 5:39 PM, John McCall <rjmccall at apple.com> wrote:

> On Mar 8, 2013, at 5:13 PM, Chandler Carruth <chandlerc at google.com> wrote:
>
> On Fri, Mar 8, 2013 at 5:07 PM, John McCall <rjmccall at apple.com> wrote:
>
>> Oh, I must have.
>>
>> Several more of your recent commits have converted variables from the
>> InitialCaps style required by the coding standard to an initialLowercase
>> form.
>>
>>
>> Oh, did that get formalized?  That's unfortunate for quite a few reasons.
>>  Maybe LLVM is consistent about it, but Clang's code base is pretty far
>> from that, particularly in IR-gen.
>>
>
> It did, and it is much more consistent in LLVM and other parts of Clang.
> Not really endorsing it, but I figure we should all suffer through it or
> get Chris to change it. ;]
>
>
> How's that reformatting tool coming along? :)
>

I believe a tool to "fix" variable capitalization already exists, maybe
Manuel can confirm that?

I mean, there's also mass inconsistency in LLVM and Clang about
> capitalization of methods.  Or rather, there isn't:  I would estimate that
> LLVM and Clang are ~90% consistent with a convention of capitalizing the
> first letter in a method name, and (1) that also contradicts the style
> guide and (2) it actually *matters* because everybody using that method has
> to be aware of it.
>

[... some quick-and-dirty regexps later...]

In include/llvm: 6275 methods starting [a-z], 1491 methods starting [A-Z]
In include/clang: 5176 methods starting [a-z], 2884 methods starting [A-Z]

So it looks like we're more consistent with the coding standard than with
the opposite convention in our public interfaces. In headers in clang's
lib/, we're somewhat the other way around: 438 starting [a-z], 669 starting
[A-Z], and specifically in clang's lib/CodeGen, we have 244 [a-z], 345
[A-Z].

These numbers aren't entirely accurate, since they don't cover the vast
numbers of Visit*, Traverse*, and Transform* functions we generate with
xmacros.


> It seems clear to me that we're going to have a red letter day sooner or
> later where we rename a bunch of LLVM APIs, and if we do that, we should
> also change the local variable convention to something that LLVM
> contributors don't essentially universally dislike.
>

Yes, I agree. I vaguely recall being told that the sticking point on this
in the past was a worry about it degrading the usefulness of tools like
'svn annotate'. If we're no longer concerned about that, perhaps it's time
to fix this once and for all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130308/c112bafe/attachment.html>