[llvm-dev] RFC: changing variable naming rules in LLVM codebase & git-blame

[Pavel Labath via llvm-dev]

On 30/07/2019 01:57, Chris Lattner via llvm-dev wrote:
> On Jul 29, 2019, at 10:58 AM, JF Bastien <jfbastien at apple.com 
> <mailto:jfbastien at apple.com>> wrote:
>>> I think that Rui rolled this out in an incredibly great way with LLD, 
>>> incorporating a lot of community feedback and discussion, and (as you 
>>> say) this thread has accumulated many posts and a lot of discussion, 
>>> so I don’t see the concern about lack of communication.
>>
>> I think there’s lack of proper communication for this effort. The RFC 
>> is all about variable naming, with 100+ responses. Sounds like a 
>> bikeshed I’ve happily ignored, and I know many others have. Even if 
>> you don’t think I’m right, I’d appreciate a separate RFC with details 
>> of what’s actually being proposed. Off the top of my head I’d expect 
>> at least these questions answered:
>>
>>   * What’s the final naming convention?
>>   * Will we have tools to auto-flag code that doesn’t follow it, and
>>     can auto-fix it?
>>   * Will we clang-format everything while we’re at it?
>>   * Will we run clang modernizer to move code to C++11 / C++14 idioms
>>     while we’re doing all this?
>>   * What’s the timeline for this change?
>>   * Is it just a single huge commit?
>>   * After the monorepo and GitHub move?
>>   * Is there a dev meeting roundtable scheduled?
>>   * What tooling exists to ease transition?
>>   * Out-of-tree LLVM backends are a normal thing. They use internal
>>     LLVM APIs that should all be auto-updatable, has this been tried?
>>   * Some folks have significant non-upstream code. Have they signed up
>>     to remedy that situation before the deadline (either by
>>     upstreaming or trying out auto-update scripts)?
>>
>>
>> LLD and LLDB are indeed good small-scale experiments. However, I think 
>> the rest of the project is quite different in the impact such a change 
>> would have. LLVM and clang expose many more C++ APIs, and have many 
>> more out-of-tree changes (either on top of upstream, or in sub-folders 
>> such as backends or clang tools). They also have many more 
>> contributors affected, and not all those contributors have the same 
>> constraints, making this much more complex. So far this discussion 
>> hasn’t seemed to care about these concerns, and I’m worried we’re 
>> about to burn a bunch of bridges. Maybe I missed this part of the 
>> discussion in the 100+ emails! Sorry if I did… but again, a simple 
>> updated RFC would solve everything.
> 
> Thanks for the detailed list here.  I have no idea what the status of 
> most of these are - it sounds like you’re generally asking “what is the 
> plan?” beyond LLD.  :-)
> 
> Rui, what are your thoughts on next steps?  LLDB seems like a logical 
> step, particularly because it uses its own naming convention that is 
> completely unlike the rest of the project.
> 

I don't speak for LLDB, but I personally would welcome such a change, 
particularly as there is some newer code in lldb now that attempts to 
follow the about-to-be-changed llvm conventions.

If we're going to go in that direction, it would be good to loop in 
lldb-dev, as I think some people don't follow llvm-dev regularly (and 
this thread in particular).

pl