[llvm-branch-commits] [cfe-branch] r143933 - in /cfe/branches/release_30: ./ test/lit.cfg

Chandler Carruth chandlerc at gmail.com
Mon Nov 7 02:20:16 PST 2011

Author: chandlerc
Date: Mon Nov  7 04:20:16 2011
New Revision: 143933

URL: http://llvm.org/viewvc/llvm-project?rev=143933&view=rev
Merging r143804:
r143804 | chandlerc | 2011-11-05 03:15:27 -0700 (Sat, 05 Nov 2011) | 38 lines

Teach Lit to pass the CC1 invocation the builtin include directory. This
is a pretty gross hack, but I don't have any significantly cleaner ideas
for this. There are several things obviously gross about it:

1) Lit shouldn't know that Clang needs this. This really that bad, as
   Lit already knows about CC1 and other internal details.
2) This hard codes the '3.0' version number, which is pretty lame.
3) This hard codes every other aspect of the resource dir structure
   which is less lame than the version number, but still not great.

However, it should bring the MSVC tests back to life, and it should
unblock the rest of the move from Frontend to Driver, so I think it's
worth a bit of grossness that is isolated in our testing infrastructure
while we figure out the best long term approach. I have the following
ideas, some of which only solve part of the problem (and thus might need
to be combined with other ideas):

a) Create a symlink or other convenience path instead of a version
b) Run 'clang' directly in the lit.cfg, look at its resource dir, and use
c) Switch all the tests to use the driver instead of CC1.
d) Hack the frontend to synthesize builtin include directories when none
   are provided by the driver.

I don't like (d) because it feels very hackish and likely to break. We
can only solve a small part of the problem with (a). I wanted to vote
for (c), but lots of the tests in this bucket are really heavily using
internal-only flags like -verify and -triple. I'm loath to complicate
them with the full driver layer. Also, switching them to the driver adds
more than just builtin headers, but all of the rest of the system

This leaves me with (b). If others like (b), I'll switch to it, but it
felt a bit icky. Nothing concrete, and the other options look
significantly worse, but I felt icky enough that I wanted to start with
a more brain-dead patch to stop the bleeding, and gauge others' feelings

    cfe/branches/release_30/   (props changed)

Propchange: cfe/branches/release_30/
--- svn:mergeinfo (original)
+++ svn:mergeinfo Mon Nov  7 04:20:16 2011
@@ -1,3 +1,3 @@

Modified: cfe/branches/release_30/test/lit.cfg
URL: http://llvm.org/viewvc/llvm-project/cfe/branches/release_30/test/lit.cfg?rev=143933&r1=143932&r2=143933&view=diff
--- cfe/branches/release_30/test/lit.cfg (original)
+++ cfe/branches/release_30/test/lit.cfg Mon Nov  7 04:20:16 2011
@@ -141,7 +141,17 @@
 config.clang = inferClang(config.environment['PATH']).replace('\\', '/')
 if not lit.quiet:
     lit.note('using clang: %r' % config.clang)
-config.substitutions.append( ('%clang_cc1', config.clang + ' -cc1') )
+# Note that when substituting %clang_cc1 also fill in the include directory of
+# the builtin headers. Those are part of even a freestanding environment, but
+# Clang relies on the driver to locate them.
+# FIXME: It might be nice to teach the frontend how to find its builtin headers
+# in some limited cases when the driver provides no hints.
+clang_builtin_includes = os.path.join(llvm_libs_dir, 'clang', '3.0', 'include')
+config.substitutions.append( ('%clang_cc1',
+                              '%s -cc1 -internal-nosysroot-isystem %s'
+                              % (config.clang, clang_builtin_includes)) )
 config.substitutions.append( ('%clangxx', ' ' + config.clang +
                               ' -ccc-clang-cxx -ccc-cxx '))
 config.substitutions.append( ('%clang', ' ' + config.clang + ' ') )

More information about the llvm-branch-commits mailing list