Re: [lldb-dev] [4.0.0 Release] Release Candidate 3 has been tagged

Pushed: 9bdd5788761d0b02cdc84104aafd6b0e835a2fc0 rc3/clang+llvm-4.0.0-rc3-x86_64-apple-darwin.tar.xz — Mehdi > On Mar 2, 2017, at 2:12 PM, Hans Wennborg via lldb-dev > wrote: > > On Thu, Mar 2, 2017 at 11:47 AM, Hans Wennborg wrote: >>

[lldb-dev] LLVM GSOC Projects Criteria Consultation (before 2/28)

Hello all, GSOC is around the corner, and the LLVM projects plans to participate again this year. For those who don’t know about GSOC, students are proposing a project that they will work on for 3 months. Amongst other, one goal for LLVM is to mentor students to become good developers and also

Re: [lldb-dev] [llvm-dev] [4.0.0 Release] Release Candidate 2 has been tagged

(stage-3 check-all fails on macOS around libcxxabi but I think it is usual). I pushed: 9df4d8a9c74ccb1aaaf934f19a48d003917c9d81 rc2/clang+llvm-4.0.0-rc2-x86_64-apple-darwin.tar.xz — Mehdi > On Feb 8, 2017, at 4:33 PM, Hans Wennborg via llvm-dev > wrote: > >

Re: [lldb-dev] Navigating STL types

> On Jan 23, 2017, at 4:13 PM, Andreas Yankopolus wrote: > > Mehdi, > >> Yes, this is a problem with our STL, we are forcing inlining and we need to >> fix this on libc++ side, it is scheduled, but we haven’t come to it yet. > > Any guesstimate as to the timeframe? Long

Re: [lldb-dev] Navigating STL types

Yes, this is a problem with our STL, we are forcing inlining and we need to fix this on libc++ side, it is scheduled, but we haven’t come to it yet. — Mehdi > On Jan 23, 2017, at 3:58 PM, Andreas Yankopolus via lldb-dev > wrote: > > How can I navigate STL types

Re: [lldb-dev] [llvm-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

Hi, FYI, I added a Green dragon job to build and test (stage 1 only right now) the release branch: http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA-release-4/ — Mehdi > On Jan 18, 2017, at 7:45 AM, Hans

Re: [lldb-dev] [llvm-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

Just pushed Darwin: d93fca2905fece5b5392a0025c2f5f09f044a17c clang+llvm-4.0.0-rc1-x86_64-apple-darwin.tar.xz — Mehdi > On Jan 18, 2017, at 7:45 AM, Hans Wennborg via llvm-dev > wrote: > > Dear testers, > > 4.0.0-rc1 was just tagged from the branch, with r292377.

Re: [lldb-dev] [cfe-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

> On Jan 18, 2017, at 7:45 AM, Hans Wennborg via cfe-dev > wrote: > > Dear testers, > > 4.0.0-rc1 was just tagged from the branch, with r292377. > > There are still open merge requests and bugs, but I'd like to get the > testing started to see what issues come up. >

Re: [lldb-dev] [cfe-dev] [llvm-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

Looks like LLVM and clang are out-of-sync. Using the script as Hans said worked for me: test-release.sh -release 4.0.0 -rc 1 -triple x86_64-apple-darwin (Triple is likely gonna be different for you). — Mehdi > On Jan 18, 2017, at 12:28 PM, Andrew Kelley via cfe-dev >

Re: [lldb-dev] [llvm-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

Hi Hans, I can test it on macOS. Is there a doc to describe what to test? I remember you pointed me to a script once… Anyone else involved in the release process on macOS? Thanks, — Mehdi > On Jan 18, 2017, at 7:45 AM, Hans Wennborg via llvm-dev > wrote: > >

[lldb-dev] Fwd: [cfe-dev] Your help needed: List of LLVM Open Projects 2017

LLDB Folks, FYI, see below, the LLDB section is empty right now. Best, Mehdi > Begin forwarded message: > > From: Vassil Vassilev via cfe-dev > Subject: [cfe-dev] Your help needed: List of LLVM Open Projects 2017 > Date: January 16, 2017 at 5:18:21 AM PST > To:

Re: [lldb-dev] [cfe-dev] [Release-testers] [Openmp-dev] [4.0 Release] Schedule and call for testers

> On Dec 5, 2016, at 12:07 PM, Hans Wennborg via cfe-dev > wrote: > > On Mon, Dec 5, 2016 at 12:02 PM, Renato Golin > wrote: >> On 5 December 2016 at 19:56, Hans Wennborg wrote: >>> I'd like

Re: [lldb-dev] [llvm-dev] [RFC] Runtime checks for ABI breaking build of LLVM

> On Nov 18, 2016, at 3:45 PM, Mehdi Amini wrote: > > Hi, > > I had to revert it, because it breaks building LLDB on MacOS. > > It turns out it would break any client that is including llvm-config.h but > not linking to libLLVMSupport. > So either: > > - we shouldn’t

Re: [lldb-dev] [llvm-dev] [RFC] Runtime checks for ABI breaking build of LLVM

Hi, I had to revert it, because it breaks building LLDB on MacOS. It turns out it would break any client that is including llvm-config.h but not linking to libLLVMSupport. So either: - we shouldn’t allow to include llvm-config.h without linking to LLVM, in which case I need to look a bit

Re: [lldb-dev] download page for LLDB at llvm.org

> On Nov 10, 2016, at 9:14 AM, Todd Fiala via lldb-dev > wrote: > > Hi all, > > I just took a look at our page here: > > http://lldb.llvm.org/download.html > > The LLDB Releases section seems pretty out of date. It seems like we

Re: [lldb-dev] [llvm-dev] GitHub Survey - Results

I’m working on it. — Mehdi > On Nov 2, 2016, at 1:43 PM, Zachary Turner via lldb-dev > wrote: > > It would be nice if the slides containing the pie-graphs showed the original > question that people were responding to. It's a little hard to make sense of > the

Re: [lldb-dev] Regenerating public API reference documentation

> On Oct 14, 2016, at 6:44 AM, Tamas Berghammer via lldb-dev > wrote: > > Hi All, > > The current LLDB API reference documentation available at > http://lldb.llvm.org/python_reference/ > and at >

Re: [lldb-dev] fate of TimeValue

> On Oct 7, 2016, at 10:19 PM, Pavel Labath wrote: > > On 7 October 2016 at 21:42, Mehdi Amini wrote: >> >>> On Oct 7, 2016, at 9:30 PM, Pavel Labath via lldb-dev >>> wrote: >>> >>> The llvm-dev thread seems to have fizzed

Re: [lldb-dev] fate of TimeValue

> On Oct 7, 2016, at 9:30 PM, Pavel Labath via lldb-dev > wrote: > > The llvm-dev thread seems to have fizzed out - I would assume they are > not interested in std::chrono. I suggest a totally different course of action: any utility (except specific to the debugger

Re: [lldb-dev] Adding D language demangling support

> On Sep 21, 2016, at 5:52 AM, Johan Engelen via lldb-dev > wrote: > > Hi all, > I recently looked into adding demangling support for D in LLDB, but got > lost in the code. > (right now, basic D support is there with: https://reviews.llvm.org/D24794 >

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 2:46 PM, Zachary Turner wrote: > > Occasionally (and in my experience *very* occasionally), you need to treat "" > as different from null. return an Optional? — Mehdi > But the frequency with which that is really necessary is much lower than >

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 2:31 PM, Greg Clayton wrote: > > We should avoid crashing if there is a reasonable work around when the input > is bad. StringRef with NULL is easy, just put NULL and zero length and don't > crash. Just because it is documented, doesn't mean it needs

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 2:19 PM, Greg Clayton wrote: > > Again, strlen is a stupid example as it is well documented. All of llvm and > clang are not. IMO that is: 1) A free claim that is easily defeated (to prove you wrong on *all* of LLVM being not document I just have to

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 20, 2016, at 10:33 AM, Greg Clayton wrote: > >> >> On Sep 19, 2016, at 2:46 PM, Mehdi Amini wrote: >> >>> >>> On Sep 19, 2016, at 2:34 PM, Greg Clayton wrote: >>> On Sep 19, 2016, at 2:20 PM, Mehdi Amini

Re: [lldb-dev] LLDB Evolution - Final Form

> On Sep 19, 2016, at 2:34 PM, Greg Clayton wrote: > >> >> On Sep 19, 2016, at 2:20 PM, Mehdi Amini wrote: >> >>> >>> On Sep 19, 2016, at 2:02 PM, Greg Clayton via lldb-dev >>> wrote: >>> >>> On Sep 19, 2016, at

Re: [lldb-dev] LLDB Evolution

> On Aug 26, 2016, at 6:12 PM, Zachary Turner via lldb-dev > wrote: > > Back to the formatting issue, there's a lot of code that's going to look bad > after the reformat, because we have some DEEPLY indented code. LLVM has > adopted the early return model for this

Re: [lldb-dev] Passing std::atomics by value

> On Aug 26, 2016, at 1:13 PM, Zachary Turner wrote: > > IOW, marking it =delete() is no different than deleting the copy constructor > above, but at least if you mark it delete, maybe someone will read the > comment above it that explains why it's deleted :) Got it, make

Re: [lldb-dev] Passing std::atomics by value

> On Aug 26, 2016, at 1:02 PM, Zachary Turner via lldb-dev > wrote: > > It seems to be. I will also make the copy constructor =delete() to make sure > this cannot happen again. Just curious: if a member has a deleted copy-ctor (like std::atomic right?), isn’t the

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

> On Jul 8, 2016, at 1:05 PM, Renato Golin wrote: > > On 8 July 2016 at 21:04, Mehdi Amini wrote: >>> What about git describe? >> >> Not a number. > > It contains a number... "tag-number-hash" > > Removing the tag and hash seems trivial. And

Re: [lldb-dev] [llvm-dev] [llvm-foundation] Sequential ID Git hook

Sent from my iPhone > On Jul 8, 2016, at 9:18 AM, Renato Golin wrote: > >> On 8 July 2016 at 03:14, Robinson, Paul wrote: >> I could see wanting to compare data from master and a release branch. If >> that means sequential IDs need to work

Re: [lldb-dev] [llvm-dev] Sequential ID Git hook

> On Jul 5, 2016, at 3:44 AM, Renato Golin via llvm-dev > wrote: > > Quick re-cap. > > After a few rounds, not only the "external server" proposal got > obliterated as totally unnecessary, but the idea that we may even need > a hook at all is now challenged. This is

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

> On Jun 28, 2016, at 1:55 AM, NAKAMURA Takumi via llvm-dev > wrote: > > It has also submodules. > https://github.com/llvm-project/llvm-project-submodule > > > Both llvm-project(-tree) and (-submodule) have

Re: [lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

> On Jun 13, 2016, at 5:56 PM, Saleem Abdulrasool <compn...@compnerd.org> wrote: > > On Mon, Jun 13, 2016 at 5:01 PM, Mehdi Amini via lldb-dev > <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: > > > On Jun 13, 2016, at 4:54 PM, Hans Wen

Re: [lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

> On Jun 13, 2016, at 4:54 PM, Hans Wennborg wrote: > > Breaking this out into a separate thread since it's kind of a separate > issue, and to make sure people see it. Thanks! > > If you have opinions on this, please chime in. I'd like to collect as > many arguments here

Re: [lldb-dev] [llvm-dev] GitHub anyone?

> On Jun 2, 2016, at 4:28 PM, Tanya Lattner wrote: > > > >> On Jun 2, 2016, at 12:18 PM, Mehdi Amini wrote: >> >> >>> On Jun 2, 2016, at 9:21 AM, Tanya Lattner via llvm-dev >>> wrote: >>> >>> I personally find this

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

> On Jun 2, 2016, at 11:51 AM, d...@cray.com wrote: > > Mehdi Amini via cfe-dev writes: > >> My opinion is that submodules or not is an implementation details. For >> the sake of this high-level discussion we should be able to keep it as >> "submodules" meaning "some

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

> On Jun 2, 2016, at 11:22 AM, d...@cray.com wrote: > > Matthias Braun via cfe-dev writes: > >> 3. Make sure we have ala llvm-project-submodules setup in the official >> account. (Optional or necessary for the buildbots?) > >> 7. Make sure bisecting with

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

> On Jun 2, 2016, at 11:22 AM, Robinson, Paul wrote: > >>> How do you get monotonically increasing number with a history graph? >> >> I think what we're trying to get is a "pushed" revision number, i.e. >> tracking the state of the upstream repositories at a given time.

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

> On Jun 2, 2016, at 11:03 AM, d...@cray.com wrote: > > Tim Northover via cfe-dev <cfe-...@lists.llvm.org> writes: > >> On 31 May 2016 at 13:45, Mehdi Amini via lldb-dev >> <lldb-dev@lists.llvm.org> wrote: >>> Apparently I wasn't very clear: llvm

Re: [lldb-dev] [llvm-dev] GitHub anyone?

> On Jun 2, 2016, at 11:01 AM, d...@cray.com wrote: > > Mehdi Amini via llvm-dev writes: > >>> Personally, I’m hugely in favor of moving llvm’s source hosting to >>> github at some point, despite the fact that I continue to dislike >>> git as a tool and consider

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

> On Jun 1, 2016, at 11:51 AM, Matthias Braun wrote: > > So here's a straw-man proposal for a github migration: > > 1. Register an official github project with the llvm foundation. > 2. Setup another (read-only) mirror of llvm.org/git at this github project > 3. Make sure we

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

> On Jun 1, 2016, at 10:19 AM, Tim Northover via llvm-dev > wrote: > > On 1 June 2016 at 10:12, Dan Liew via cfe-dev wrote: >> the directories for each submodule will stay empty. Thus it isn't >> necessary to pull down all the sources when

Re: [lldb-dev] [llvm-dev] GitHub anyone?

> On May 31, 2016, at 4:06 PM, Robinson, Paul wrote: > > > >> -Original Message- >> From: mehdi.am...@apple.com [mailto:mehdi.am...@apple.com] >> Sent: Tuesday, May 31, 2016 3:54 PM >> To: Robinson, Paul >> Cc: Bill Kelly; Clang Dev; LLDB Dev;

Re: [lldb-dev] [llvm-dev] GitHub anyone?

> On May 31, 2016, at 2:01 PM, Bill Kelly via llvm-dev > wrote: > > Chris Lattner via llvm-dev wrote: >> Personally, I’m hugely in favor of moving llvm’s source hosting to github at >> some point, despite the fact that I continue to dislike git as a tool and >>

Re: [lldb-dev] [llvm-dev] GitHub anyone?

> On May 31, 2016, at 1:31 PM, Renato Golin wrote: > > On 31 May 2016 at 21:28, Mehdi Amini wrote: >> Ideally, I'd prefer the cross-repository to be handled with an extra layer, >> in a way similar as described in: >>

Re: [lldb-dev] [llvm-dev] GitHub anyone?

> On May 31, 2016, at 1:16 PM, Chris Lattner via llvm-dev > wrote: > >> On May 31, 2016, at 12:31 PM, Renato Golin via llvm-dev >> wrote: >> There has been some discussion on IRC about SVN hosting and the perils >> of doing it ourselves. The

Re: [lldb-dev] [cfe-dev] [llvm-dev] [3.8 Release] RC1 has been tagged

If the test-suite setup with CMake is broken, why not replace the CMake auto-detection of the test-suite with an error? Something like: diff --git a/CMakeLists.txt b/CMakeLists.txt index d96afc465177..918da6f6c945 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -693,11 +693,7 @@ endif()