r176428 - Perform non-overload placeholder conversions on the operands

[John McCall]

On Mar 8, 2013, at 6:25 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 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].

Hmm.  Raw counts here are going to be dominated by get/set/is methods, which (1) we're very consistent about lowercasing but (2) are a huge exception.  "Action" methods, like those that dominate Sema, Parser, CGF, and CGM, are overwhelmingly uppercased — with CGF and CGM being less consistent, but only because I'm personally okay with inconsistency if it means we're making progress — a "better slouching towards heaven than marching heads-high to hell" sort of thing, which I don't think is how sabre sees it.

LLVM uses free functions more than we do, and they're also basically universally uppercased.

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

I don't know why that would change the count, actually — one of them apiece counts as source code.
 
> 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.

This is unfortunately still a concern.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130310/416dfd93/attachment.html>