Re: [boost] [config][clang] Does <boost/config/compiler/clang.hpp> need updating?

Subject: Re: [boost] [config][clang] Does <boost/config/compiler/clang.hpp> need updating?
From: Doug Gregor (doug.gregor_at_[hidden])
Date: 2011-02-05 13:26:20

On Wed, Feb 2, 2011 at 1:46 PM, Bryce Lelbach
<admin_at_[hidden]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I believe I've got the de-facto role of clang (linux) maintainer.
> Clang-linux C++0x support is very shaky (turning it on can break stdlib stuff)
> unless you have a clang compiled GNU stdlib or libc++. Until Redhat-based and
> Debian- based distros start shipping Clang with either 0.) clang-compiled GNU
> stdlib or 1.) clang friendly stdlib, we should probably only try to use C++0x
> support on Darwin. I need to investigate this more, though.

There are a number of inter-related issues here, so let me try to detangle them.

Clang itself is just now getting some C++0x support. It has rvalue
references, variadic templates, decltype, static_assert, and some
other goodies. We think it's in decent shape, but obviously we need
more testing coverage.

Clang works with a few different C++ standard libraries, and that's
where C++0x gets interesting/messy:

  - libc++ (Clang/LLVM's new C++0x standard library) works great with
Clang's C++0x support.

  - libstdc++ (GCC's C++ standard library) has problems with Clang's
C++0x support, for different reasons in different versions:
      4.2: "works", because it doesn't use any C++0x features, but of
course you don't have any library support
      libs
      4.3, 4.4: fails, because the library was written at a time when
rvalue references could bind to lvalues, which they now can't. so,
Clang C++0x (correctly) rejects the code. This is just a casualty of
shipping compilers and libraries based on an incomplete working paper.
      4.5: fails, because the library uses generalized initializer
lists, which Clang does not yet implement.
      4.6: presumably fails because of both generalized initializer
lists and constexpr, neither of which Clang does not yet implement.

So, at this point, it only really makes sense to test Clang's C++0x
support either with libstdc++'s 4.2's non-C++0x library or with
libc++. (I haven't tried Dinkumware or Apache; I suspect they'll need
to be taught about Clang first).

> Hopefully there's a way to turn on C++0x support for clang by defining a macro,
> without making the stdlib believe that clang supports C++0x.

I don't think this is going to be practical. For libstdc++, we'll
probably have to write off 4.3 and 4.4 as great experiments with C++0x
that shouldn't be used for writing actual C++0x code, and we'll have
to wait until Clang's C++0x support catches up with GCC used of C++0x
in the library for 4.5/4.6.

Regarding Beman's original question about
<boost/config/compiler/clang.hpp>, I'll be happy to keep it up-to-date
with feature checks for Clang, since I'm also the maintainer of the
feature checks on the Clang side. I'm not a good candidate for
platform champion, though, because I don't watch Boost closely enough
to be helpful.

  - Doug