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

Tue Jul 30 02:53:34 PDT 2019

Is the plan for LLDB to just adapt the code that is trying to follow the new code style or also the code using the LLDB code style?

I’m in general in favor of moving LLDB to the LLVM code style because it makes the LLDB code that interfaces with Clang/LLVM less awkward to write (e.g. no more code style confusion when inheriting from a Clang classes inside the LLDB code base). But I think if we do this, then it should be discussed/planned in more detail and in a lldb-dev thread that actually reaches all/most LLDB devs. I wouldn’t even have read this thread if Pavel didn’t CC lldb-dev.

As a side note: LLDB has downstream projects that will suffer from this, but I believe (?) LLD has no downstream projects. So I think LLD is maybe also a good candidate to test this?

- Raphael

> On Jul 30, 2019, at 8:38 AM, Pavel Labath via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev