We'll be at Tied House as usual, starting on Thursday the 7th at 7pm!
If you can, help us plan and RSVP here:
https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyzdbkb/
See everyone there!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
I'm also in favor of linear history, option #1.
FWIW I don't think lacking tight controls to prevent merges is going to be
a huge deal. We already restrict who can commit, and there are lots of
other rules you have to follow.
We might get an accidental merge or two every once in a while, but I
> The way it decides that there are "outdated comments" and that those
comments should be hard to does not win it any points in my book (Hubert
Tong)
IIUC, Github has recently changed this, and is now more like Phabricator.
(in that it now seems to add a mark to say the diff is likely outdated,
It would be easy to add the equality or comparison and other operators to any
items that don't have them. I am not a fan of adding user data. It can't live
be in the SBXXX object itself, because we can't change the member variables in
the objects for API backward compat issues. If it is inside
https://bugs.llvm.org/show_bug.cgi?id=40588
Bug ID: 40588
Summary: NativeProcessLinux::MonitorCallback incorrectly logs
value of libc "signal" function
Product: lldb
Version: unspecified
Hardware: PC
OS:
