[llvm] r179601 - Cleanup naming: DataLayout s/TD/DL/

[Sean Silva]

On Tue, Apr 16, 2013 at 6:44 PM, Eli Bendersky <eliben at google.com> wrote:

>
>
> ---------- Forwarded message ----------
> From: Eli Bendersky <eliben at google.com>
> Date: Tue, Apr 16, 2013 at 3:44 PM
> Subject: Re: [llvm] r179601 - Cleanup naming: DataLayout s/TD/DL/
> To: Jim Grosbach <grosbach at apple.com>
>
>
> On Tue, Apr 16, 2013 at 2:44 PM, Jim Grosbach <grosbach at apple.com> wrote:
>
>>
>> On Apr 16, 2013, at 2:32 PM, Eli Bendersky <eliben at google.com> wrote:
>>
>> On Tue, Apr 16, 2013 at 12:05 PM, Jim Grosbach <grosbach at apple.com>
>> wrote:
>>
>>> DL and dl often are used for debugloc elsewhere. Thoughts on
>>> alternatives?
>>
>>
>> Good point. I don't think there should be a lot of places where there's a
>> conflict between the two, and wherever it is, the conflict can be resolved
>> by using longer an more meaningful names. I'm not sure it's the only place
>> in LLVM code where there's such a conflict...
>>
>> Eli
>>
>> Sounds reasonable. Just something that caught my eye. Thanks!
>>
>>
>
> Rats... a lot of work has to be done to make it consistent:
>
> $ git grep "\bTD\b" | grep "\.cpp"|wc -l
> 1766
> $ git grep "\bDL\b" | grep "\.cpp"|wc -l
> 2705
>
> And there are a number of places where both are used (FastIsel and its
> target subclasses, for instance).
>
> DL makes more sense for DataLayout because it's most similar to other
> "information classes", i.e:
>
>   const TargetMachine &TM;
>   const DataLayout &TD;               <------------ DL
>   const TargetInstrInfo &TII;
>   const TargetLowering &TLI;
>   const TargetRegisterInfo &TRI;
>
> So DebugLoc probably has to cede its throne and be converted to DbgLoc or
> something similar? Again, that's ~4.5K substitutions to make in order to be
> completely consistent :-(
>
>
Maybe it would be possible to whip up something with libTooling to automate
it? You may be able to get the majority of them with a couple lines of
ASTMatchers. Or maybe directly using a RecursiveASTVisitor would be simpler.

This whole issues actually brings up an interesting issue related to coding
style. It seems like it is generally preferable that all variables of a
given type across the codebase have the same name (subject to modifications
if there's more than one in scope, and of course using longer names in the
usual places where longer names are used). It would be interesting to
collect metrics about which types have the most naming variability.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130416/d2303e76/attachment.html>