[LLVMbugs] [Bug 21002] New: Confusing error message when using modules with libc++ without -std=c++11

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=21002

            Bug ID: 21002
           Summary: Confusing error message when using modules with libc++
                    without -std=c++11
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Modules
          Assignee: unassignedclangbugs at nondot.org
          Reporter: nicolasweber at gmx.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

I tried playing with using modules when building ninja (but this isn't
ninja-specific):

  cd ~/src
  git clone https://github.com/martine/ninja.git
  cd ninja
  CXX=path/to/llvm-build/Release+Asserts/bin/clang++ \
  CFLAGS="-isysroot $(xcrun -show-sdk-path) -fmodules -fcxx-modules" \
  ./configure.py
  ninja

This is with a clang build that has libc++ headers installed to the build
directory, so they get picked up from there. (If you're not on OS X, omit the
-isysroot and its argument).

This fails with:

While building module 'std' imported from src/build_log.h:18:
In file included from <module-includes>:3:
/Users/thakis/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/../include/c++/v1/atomic:539:2:
error: <atomic> is not implemented
#error <atomic> is not implemented
 ^
In file included from src/build_log.cc:15:
src/build_log.h:18:10: fatal error: could not build module 'std'
#include <string>
 ~~~~~~~~^


After looking through libc++ headers, the problem seems to be that cxx_atomic
is only true in c++11 mode. Maybe libc++'s modules.modulemap should omit the
"atomic" module when not in c++11 mode? (We don't want to build ninja in c++11
mode so that it can run on old systems where the c++ library doesn't have c++11
features yet.)



(Also, in addition to that, a more minor issue: After that, there are 10 more
errors for other TUs that look like

src/deps_log.h:18:10: fatal error: could not build module 'std'
#include <string>
 ~~~~~~~~^
1 error generated.

These just clutter up output and aren't actionable. I understand why these get
emitted, but maybe this could be handled more intelligently somehow. Maybe the
original error could be stored in the module so that it can be printed from
other TUs, or clang could not emit module errors if it had to wait for the
module lock and then discovered that an error is stored in there – in that
case, it knows that the error has already been produced. Hm, I suppose failing
without any error is pretty weird too. My first reaction to this was "it
failed, but why?", and only later did I think of scrolling up.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140919/68f12ec8/attachment.html>