[lldb-dev] Linux build broken by clang commit - r170482

[David Blaikie]

On Thu, Dec 20, 2012 at 9:50 PM, Sean Hermany <sean at crittercism.com> wrote:
> Was in the process of building lldb on linux for the first time and finally
> got stuck on compilation errors in Expression/ClangASTSource.cpp.
>
> It looked to me like the code was expecting an STL pair but getting a
> fundamentally different type. (I think) I eventually tracked it down to this
> commit -
>
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121217/070026.html
>
> which looks like a non-trivial change to me (though I'm hardly well versed
> in llvm/clang/lldb code).

It's a fairly mechanical change. What used to be a std::pair<T*, T*>
representing the usual C++ iterator half-open range [begin, end), was
changed to an llvm::ArrayRef, which also represents a half-open range
with begin() and end() and various other common container-like
operations. Just a bit more high-level than a pair of iterators.

> Apparently there is a linux build bot run at uuic, which was experiencing
> the same error I was - here is the first broken build:
>
> http://lab.llvm.org:8011/builders/lldb-x86_64-linux/builds/2107

Fair point. We should probably set this bot up to actually send
fail-mail. I didn't get any report of this failure.

Also, I assume if no lldb developers fixed this/complained about it,
then they're not actually tracking upstream head at the moment, or not
very often. If I were to make the lldb fix to match this change it
would necessitate all of the lldb developers bringing their clang/llvm
copies up to ToT - I'm not sure if this is what they want to do. (I
hope it is what they want to do, but the fact that no one complained
about it leaves me a bit confused)

> A few questions - It seems to me that lldb used to purposely tie itself to
> specific revisions of llvm and clang to avoid the instability of an actively
> developed project, though some time in the past few months things changed
> such that lldb trunk should always build against llvm and clang's trunk
> revisions. Out of curiosity, is there no reciprocity between the llvm and
> clang developers? It seems like that change would have not passed
> build/regression tests against lldb.

It's fairly common for people to build llvm+clang together, but beyond
that any other project is a bit more optional/less common - the less
common the combination is, the longer a break will persist before a
developer on that less common project syncs up LLVM/clang &
discovers/fixs/complains about it.

The only other device we have are build bots - and they really need to
send email on failure. If the LLDB bot is stable & green (we can make
it green again after my change - the fix shouldn't be difficult) I'd
love to make it send failure email, report to #llvm if possible, etc.

> Since it's the holiday season, I'm not going to hold my breath on a patch -
> is my best bet just going back to the last revision of of lldb that built,
> and syncing to the closest SVN revisions for clang and llvm at that time?
> Would appreciate any suggestions from someone who builds and uses lldb on
> linux.
>
> (BTW, sorry for pointing this out and not submitting a patch, but I don't
> think I'd be able to wrap my head around everything fast enough to fix this
> one. Thanks for all of your contributions though!)

It should be a fairly mechanical fix if you want to try your hand at
it. There are several examples of all the different styles of old
usage & how they could be updated to the new usage in the original
patch I committed.

If that's really beyond your time/capacity right now, I guess what you
have in mind - syncing Clang/LLVM back to just before that commit is
probably fine (it must be how the rest of the LLDB team is working,
otherwise they would've seen the build failure too)

Sorry for the breakage,
- David