[lldb-dev] [9.0.0 Release] Release Candidate 1 is here

[Hans Wennborg via lldb-dev]

Hi everyone,

9.0.0-rc1 was just tagged from the release_90 branch at r367217
(tagged as llvmorg-9.0.0-rc1 in the Git monorepo).

Source code and docs are available at https://prereleases.llvm.org/9.0.0/#rc1

Binaries will be added as they become available.

Please file bug reports for any issues you find as blockers of
https://llvm.org/PR42474

Release testers: please start your engines, run the script, share your
results, and upload binaries.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Pavel Labath via lldb-dev]

On 30/07/2019 01:57, Chris Lattner via llvm-dev wrote:
On Jul 29, 2019, at 10:58 AM, JF Bastien > 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