llvm dev - Jul 2019 - RFC: changing variable naming rules in LLVM codebase & git-blame

On Jul 29, 2019, at 10:58 AM, JF Bastien <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.

-Chris




> 
>> The reason that I personally pivoted to believe that a “do everything
all at once in one commit generated by Rui’s script” approach was the right
thing was seeing how lld contributors were able to cleanly move forward even
when they have significant out of tree changes - they merged to the N-1 commit,
then ran Rui's script on *their* trees, and were caught up with commit N. 
This seems to have provided a very smooth transition path, where the conversion
was merely a bump in the road, not a major mountain to climb over.
> 
> That sounds fine to me. I just want to make sure everyone knows they’re
about to have to climb a little hill. Surprise hills are the worst.
> 
> 
>> In any case, I hope that we as a community don’t end up in a place
where we are afraid of doing sweeping changes that make the codebase better.
> 
> Sure the current naming is ugly and inconsistent, but honestly I don’t
really care about naming. The one upside I see from this change is the same
clang-format has brought: we can finally stop picking nits and arguing about
stuff that doesn’t matter.
> 
> I agree that we should be able to make sweeping changes. I’m saying that I
don’t think the direction I see us going in right now seems like it’ll work out
well, and it seems easy to address my worries.
> 
> 
>> It is important to continually reinvest in the health of the codebase,
and it isn’t bad to incentivize people to merge their changes upstream.
> 
> Agreed. However, as you know very well, merging upstream changes isn’t
something that’s done over a weekend. First people have to know that a large
change is coming and they probably should plan for upstreaming. Second we should
give these folks enough time to do the upstreaming, and leave them enough slack
in case they fall behind.
> 
> 
>> Being overwhelmingly afraid of ‘breaking history’ is a path that leads
stagnation and ultimate replacement by newer technologies.  There are many other
projects that have suffered this fate, usually for a combination of reasons
including things like this.
> 
> Again, this concern is small compared to the others I’ve expressed. Let’s
have it as one item on the list of things we want answers to before moving
forward. I think the rest of what I’m raising is much more important.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190729/4d9768e2/attachment-0001.html>

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

(Sorry for not replying to this thread -- I was on a business trip last
week.)

Thank you for sharing your concerns, JF. I share your concerns. I
personally don't think my communication was improper, as I clearly
expressed my intent to make that change, gave heads-ups multiple times, and
the change was not committed in a rush. That being said, there's room
for improvement. As you wrote, in hindsight, replying to a thread with 100+
posts was probably not ideal. In addition to that, people might not have
complained to me because I'm the code owner of lld subtree and as long as
I'm editing files under the subtree they might not have cared too much
about it (although I don't think I have any authority when it comes to the
identifier naming style even within lld directory, and I don't have any
intention to diverge from the LLVM's coding style.) LLVM and Clang are an
order of magnitude larger than lld in many aspects including the number of
people involved, the number of out-of-tree repos, the length of the
history, etc. Naturally a sweeping change to LLVM/Clang would cause more
concerns, and we need to address that before making a sweeping change.

It's not only you who requested me send a new RFC to the mailing list if
I'm planning to roll this out to the entire repository, and that's
definitely my next thing to do.

On Tue, Jul 30, 2019 at 8:57 AM Chris Lattner <clattner at nondot.org>
wrote:
> On Jul 29, 2019, at 10:58 AM, JF Bastien <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.
>
Besides sending a new RFC, I think the next step is to improve a tool so
that a sweeping change can be created mechanically. I was actually trying
to improve clang-tidy for the variable renaming; clang-tidy already has a
feature to rename identifiers, but that doesn't work well for our purposes
in various corner cases, and because of the size of the repository, there
are lots of corner cases, so I need to improve it. Once the tool is done,
I'd try to apply the tool to the *entire* repo to rename everything all at
once to see if such change is feasible. If it's feasible, I'd think
that's
probably better for everybody including downstream repo maintainers.

But all in all, the next logical step is to start a new thread with a
concrete proposal how we'd like to rename identifiers and how we'd like
to
do that, to get a more concrete consensus and address concerns.

(FWIW, I built the head-of-the-tree git and tried to use `git blame
--ignore-rev` to see how it works to lld, and it looks like it's working
pretty well. I'll mention that in an RFC.)

-Chris
>
>
>
>
>
>
> The reason that I personally pivoted to believe that a “do everything all
> at once in one commit generated by Rui’s script” approach was the right
> thing was seeing how lld contributors were able to cleanly move forward
> even when they have significant out of tree changes - they merged to the
> N-1 commit, then ran Rui's script on *their* trees, and were caught up
with
> commit N.  This seems to have provided a very smooth transition path, where
> the conversion was merely a bump in the road, not a major mountain to climb
> over.
>
>
> That sounds fine to me. I just want to make sure everyone knows they’re
> about to have to climb a little hill. Surprise hills are the worst.
>
>
> In any case, I hope that we as a community don’t end up in a place where
> we are afraid of doing sweeping changes that make the codebase better.
>
>
> Sure the current naming is ugly and inconsistent, but honestly I don’t
> really care about naming. The one upside I see from this change is the same
> clang-format has brought: we can finally stop picking nits and arguing
> about stuff that doesn’t matter.
>
> I agree that we should be able to make sweeping changes. I’m saying that I
> don’t think the direction I see us going in right now seems like it’ll work
> out well, and it seems easy to address my worries.
>
>
> It is important to continually reinvest in the health of the codebase, and
> it isn’t bad to incentivize people to merge their changes upstream.
>
>
> Agreed. However, as you know very well, merging upstream changes isn’t
> something that’s done over a weekend. First people have to know that a
> large change is coming and they probably should plan for upstreaming.
> Second we should give these folks enough time to do the upstreaming, and
> leave them enough slack in case they fall behind.
>
>
> Being overwhelmingly afraid of ‘breaking history’ is a path that leads
> stagnation and ultimate replacement by newer technologies.  There are many
> other projects that have suffered this fate, usually for a combination of
> reasons including things like this.
>
>
> Again, this concern is small compared to the others I’ve expressed. Let’s
> have it as one item on the list of things we want answers to before moving
> forward. I think the rest of what I’m raising is much more important.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190730/b8b63c30/attachment.html>

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

> On Jul 30, 2019, at 2:50 AM, Rui Ueyama <ruiu at google.com> wrote:
> 
> (Sorry for not replying to this thread -- I was on a business trip last
week.)
No worries! I’m guilty of ignoring the entire thread since February ;-)

> Thank you for sharing your concerns, JF. I share your concerns. I
personally don't think my communication was improper, as I clearly expressed
my intent to make that change, gave heads-ups multiple times, and the change was
not committed in a rush. That being said, there's room for improvement. As
you wrote, in hindsight, replying to a thread with 100+ posts was probably not
ideal.
I completely understand how, in the thick of the discussion, you were doing what
seems right and proper. All I’m getting at is that from the outside none of the
changes in approach came through. I didn’t want to imply any malice or anything,
sorry for sounding that way.

> In addition to that, people might not have complained to me because I'm
the code owner of lld subtree and as long as I'm editing files under the
subtree they might not have cared too much about it (although I don't think
I have any authority when it comes to the identifier naming style even within
lld directory, and I don't have any intention to diverge from the LLVM's
coding style.) LLVM and Clang are an order of magnitude larger than lld in many
aspects including the number of people involved, the number of out-of-tree
repos, the length of the history, etc. Naturally a sweeping change to LLVM/Clang
would cause more concerns, and we need to address that before making a sweeping
change.
> 
> It's not only you who requested me send a new RFC to the mailing list
if I'm planning to roll this out to the entire repository, and that's
definitely my next thing to do.
Great, I appreciate it.

> On Tue, Jul 30, 2019 at 8:57 AM Chris Lattner <clattner at nondot.org
<mailto:clattner at nondot.org>> 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.
> 
> Besides sending a new RFC, I think the next step is to improve a tool so
that a sweeping change can be created mechanically. I was actually trying to
improve clang-tidy for the variable renaming; clang-tidy already has a feature
to rename identifiers, but that doesn't work well for our purposes in
various corner cases, and because of the size of the repository, there are lots
of corner cases, so I need to improve it. Once the tool is done, I'd try to
apply the tool to the *entire* repo to rename everything all at once to see if
such change is feasible. If it's feasible, I'd think that's probably
better for everybody including downstream repo maintainers.
> 
> But all in all, the next logical step is to start a new thread with a
concrete proposal how we'd like to rename identifiers and how we'd like
to do that, to get a more concrete consensus and address concerns.
Thank you.

> (FWIW, I built the head-of-the-tree git and tried to use `git blame
--ignore-rev` to see how it works to lld, and it looks like it's working
pretty well. I'll mention that in an RFC.)
Nice!

> -Chris
> 
> 
> 
> 
> 
>> 
>>> The reason that I personally pivoted to believe that a “do
everything all at once in one commit generated by Rui’s script” approach was the
right thing was seeing how lld contributors were able to cleanly move forward
even when they have significant out of tree changes - they merged to the N-1
commit, then ran Rui's script on *their* trees, and were caught up with
commit N.  This seems to have provided a very smooth transition path, where the
conversion was merely a bump in the road, not a major mountain to climb over.
>> 
>> That sounds fine to me. I just want to make sure everyone knows they’re
about to have to climb a little hill. Surprise hills are the worst.
>> 
>> 
>>> In any case, I hope that we as a community don’t end up in a place
where we are afraid of doing sweeping changes that make the codebase better.
>> 
>> Sure the current naming is ugly and inconsistent, but honestly I don’t
really care about naming. The one upside I see from this change is the same
clang-format has brought: we can finally stop picking nits and arguing about
stuff that doesn’t matter.
>> 
>> I agree that we should be able to make sweeping changes. I’m saying
that I don’t think the direction I see us going in right now seems like it’ll
work out well, and it seems easy to address my worries.
>> 
>> 
>>> It is important to continually reinvest in the health of the
codebase, and it isn’t bad to incentivize people to merge their changes
upstream.
>> 
>> Agreed. However, as you know very well, merging upstream changes isn’t
something that’s done over a weekend. First people have to know that a large
change is coming and they probably should plan for upstreaming. Second we should
give these folks enough time to do the upstreaming, and leave them enough slack
in case they fall behind.
>> 
>> 
>>> Being overwhelmingly afraid of ‘breaking history’ is a path that
leads stagnation and ultimate replacement by newer technologies.  There are many
other projects that have suffered this fate, usually for a combination of
reasons including things like this.
>> 
>> Again, this concern is small compared to the others I’ve expressed.
Let’s have it as one item on the list of things we want answers to before moving
forward. I think the rest of what I’m raising is much more important.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190730/c516cdf5/attachment.html>

On Tue, Jul 30, 2019 at 11:51 AM Rui Ueyama via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>> 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.
>
> Besides sending a new RFC, I think the next step is to improve a tool so
that a sweeping change can be created mechanically. I was actually trying to
improve clang-tidy for the variable renaming; clang-tidy already has a feature
to rename identifiers, but that doesn't work well for our purposes in
various corner cases, and because of the size of the repository, there are lots
of corner cases, so I need to improve it. Once the tool is done, I'd try to
apply the tool to the *entire* repo to rename everything all at once to see if
such change is feasible. If it's feasible, I'd think that's probably
better for everybody including downstream repo maintainers.
Agreed on the necessity of creating such a sweeping change
mechanically, and for the tool to work robustly.

The one giant concern here is disruption for people doing longer-term
work on branches of LLVM. There are basically two models that I'm
aware of people using:

1. Have a "local" branch with regular `git merge`s from
"master".
2. Have a "local" branch which is regularly `git rebase`d on top of
"master".

In both cases, commits may be cherry-picked to master.

*If* the rename tool is robustly enough, these workflows can probably
be accommodated. For example, for the rebase workflow, you currently
have:

  M1 -> M2 -> (M3) -> L1 -> L2 -> L3

where M3 is the tip of master. After applying the rename on master, you get:

  M1 -> M2 -> M3 -> R(M3)
                \
                 -> L1 -> L2 -> L3

By applying the rename to all trees in the local branch, it should be
possible to generate a "smarter rebase" of the form:

  M1 -> M2 -> M3 -> R(M3) -> R(L1) -> R(L2) -> R(L3)

I don't know if tools already exist to facilitate this, but I'd
consider it a necessary precondition for making such a major change.

> But all in all, the next logical step is to start a new thread with a
concrete proposal how we'd like to rename identifiers and how we'd like
to do that, to get a more concrete consensus and address concerns.
Agreed.

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.