[llvm-commits] [llvm] r64827 - in /llvm/trunk: include/llvm/CodeGen/SelectionDAG.h include/llvm/CodeGen/SelectionDAGNodes.h lib/CodeGen/SelectionDAG/DAGCombiner.cpp lib/CodeGen/SelectionDAG/LegalizeDAG.cpp lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp lib/CodeGen/SelectionDAG/SelectionDAG.cpp lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp lib/Target/PowerPC/PPCISelLowering.cpp lib/Target/X86/X86ISelLowering.cpp

[Dale Johannesen]

On Feb 17, 2009, at 2:52 PMPST, Scott Michel wrote:
>>>
>>>> (Note: Eventually, commits like this will be handled via a pre- 
>>>> commit hook that
>>>> does this automagically, as well as expand tabs to spaces and  
>>>> look for 80-col
>>>> violations.)
>>>
>>> the last time I read the subversion book, it recommended not doing  
>>> this.
>>> They instead advised having a script that rejects a commit if it  
>>> introduces
>>> trailing whitespace.
>>
>> Whoa!  There is absolutely no reason (except pedantry) to disallow  
>> this, and everybody's time would be better spent working on things  
>> that actually matter.
>> If you've got an editor that makes changes to your code you didn't  
>> tell it to, that's a serious bug; I'd either fix it or get a  
>> different editor.
>> I realize not everybody sees things that way, but I see no reason  
>> your misguided opinion should interfere with my work.:)  A script  
>> along the lines Scott suggests is OK (assuming it doesn't slow  
>> things down noticeably), but I strongly object to having patches  
>> rejected for mere pedantry.
>
> Wait a second -- there's a bit of an overreaction to the "Note:",  
> IMNSHO.

I'm reacting to the suggestion that patches that don't conform to your  
preference should be rejected automatically, not to your note.  I  
understand it was not your suggestion.

One observation I have after years of suffering through working on gcc  
is that people on that project waste an incredible amount of time  
worrying about this and other coding style issues that simply Do Not  
Matter.  I think it's a major reason gcc is so far behind current  
technology and I don't want to see llvm go down that road.

> It's got nothing to do with "an editor that changes your code you  
> didn't tell it to"; it's not as if vim or Eclipse functionally  
> changed the code. The editor is merely doing some grooming that's  
> functionally a NOP. Many editors do this, including Emacs with the  
> right flags set. Heck, even NetBeans does this by default as does  
> Eclipse.

Another reason I'm sticking with Emacs.  This sort of thing isn't  
always safe; for example, the dialect supported by early versions of  
gcc allowed newlines in the middle of strings, so trailing spaces were  
semantically significant.  For another, the difference between tabs  
and spaces is semantically significant in some versions of make.

And as a matter of theory, letting a tool's behavior drive your  
workflow is not the way things are supposed to be.  Tools are to do  
what you want, not to make you adapt to what they do.