On 30/07/2019 01:57, Chris Lattner via llvm-dev wrote:
On Jul 29, 2019, at 10:58 AM, JF Bastien <jfbast...@apple.com
<mailto:jfbast...@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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
