similar to: lit: dependent substitutions?

Hi Michael, On Thu, Dec 7, 2017 at 3:16 AM, Michael Zolotukhin <mzolotukhin at apple.com> wrote: > > Nice to IWYU developers here:) I wonder how hard it would be to run IWYU on > LLVM/Clang (or, if it’s supposed to work, I wonder what I did wrong). There are known problems with running IWYU over LLVM/Clang -- Zachary Turner made an attempt a while back to get it up and running.

Yea at first I was worried that maybe I changed the semantics of how it looked in PATH, and you had clang-func-mapping in your PATH somewhere before but now lit was building a different PATH. But I looked at that change and it wasn't even creating that substitution before. So it looks like that CL is indeed the problem. On Fri, Sep 22, 2017 at 11:38 AM Vedant Kumar <vsk at apple.com>

Looking, thanks for the report. On Fri, Sep 22, 2017 at 11:22 AM Vedant Kumar <vsk at apple.com> wrote: > As of r313998, this workflow no longer works: > > cd <build-dir> > ./bin/llvm-lit <src>/llvm/tools/clang/test/CoverageMapping > > I get: > > llvm-lit: /Users/vk/src/llvm.org-coverage-braces/llvm/tools/clang/test/ > lit.cfg.py:97: note: using

As of r313998, this workflow no longer works: cd <build-dir> ./bin/llvm-lit <src>/llvm/tools/clang/test/CoverageMapping I get: llvm-lit: /Users/vk/src/llvm.org-coverage-braces/llvm/tools/clang/test/lit.cfg.py:97: note: using clang: '/Volumes/Builds/llvm.org-coverage-braces-RA/bin/clang' llvm-lit:

Ah, the problem goes away once I build clang-func-mapping. I stripped some stuff out, but here's pretty much what clang/test/lit.cfg.py says my PATH is: ** PATH **: /Volumes/Builds/llvm.org-coverage-braces-RA/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin I wonder how this ever worked before, when I didn't have clang-func-mapping built. Anyway, thanks for your help! vedant >

On Mon, Dec 11, 2017 at 3:37 PM, Mikhail Zolotukhin via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hi Kim, > > On Dec 10, 2017, at 7:39 AM, Kim Gräsman <kim.grasman at gmail.com> wrote: > > Hi Michael, > > On Thu, Dec 7, 2017 at 3:16 AM, Michael Zolotukhin > <mzolotukhin at apple.com> wrote: > > > Nice to IWYU developers here:) I wonder how

This works for me. Can you run "which clang-func-mapping" and also add a line to clang/test/lit.cfg.py to print the value of config.environment['PATH']? On Fri, Sep 22, 2017 at 11:27 AM Zachary Turner <zturner at google.com> wrote: > Looking, thanks for the report. > > On Fri, Sep 22, 2017 at 11:22 AM Vedant Kumar <vsk at apple.com> wrote: > >> As

> On Sep 22, 2017, at 11:36 AM, Vedant Kumar <vsk at apple.com> wrote: > > Ah, the problem goes away once I build clang-func-mapping. > > I stripped some stuff out, but here's pretty much what clang/test/lit.cfg.py says my PATH is: > > ** PATH **: /Volumes/Builds/llvm.org-coverage-braces-RA/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin > > I wonder how

On 10/12/2013 04:20, Sean Silva wrote: > The classic way to do this sort of checking is by hacking into the > tool that actually interprets it (i.e. lit in this case). Considering > that lit is Python, it should be pretty easy to insert an ad-hoc regex > check (or even something substantially more sophisticated). E.g. > insert code into TestRunner.py's

I'm a little late to the party, but one observation that I haven't seen mentioned is that simply removing #includes and testing that the program compiles is not guaranteed to be a correct transformation. Imagine, for example, that a header file provides an overload of a function that is a better match than one found elsewhere. It will compile either way, but without the #include, you

Hey all, IWYU maintainer here. I wanted to make a small observation. Surprisingly, IWYU will most often *add* includes to a reasonably well-factored codebase, and this ties into Chris' comment: > Beyond that though, this seems like obvious > goodness to reduce coupling in the codebase. Just blindly removing includes will probably increase coupling, not reduce it, because it optimizes

On Sun, Dec 8, 2013 at 9:04 AM, Alp Toker <alp at nuanti.com> wrote: > > On 08/12/2013 13:12, Chandler Carruth wrote: > >> >> * Removing trailing \ will introduce the neat property that >>> >>> one RUN line corresponds precisely to one command that's >>> executed. This is good for humans and will enable

Hello all, I am writing test cases which are dedicated to be executed by llvm-lit. Most of my test cases have the same logic but different types. For example: // RUN: %clang_cc1 -fsyntax-only func (int a) { a = 3; } // RUN: %clang_cc1 -fsyntax-only func (char a) { a = 3; } // RUN: %clang_cc1 -fsyntax-only func (unsigned a) { a = 3; } Now I put them in three different test cases but it

Hi, I use llvm-lit in my own project. Works fine so far. However, executing the tests, I get output directories which are empty. Whats the role of them? I could not find any hint in the docu. I was expecting that e.g. for RUN: X, the output of X would be located there. I can use RUN: X > log, then I get a log file right besides the test file, and not in oputput. Where can I find more docu

Morning, Will! 2012/7/12 Will Schmidt <will_schmidt at vnet.ibm.com>: > llvm]$ gmake check > llvm[0]: Running test suite > gmake[1]: Entering directory `/home/willschm/llvm/test' > Making LLVM 'lit.site.cfg' file... > sed: file lit.tmp line 8: unknown option to `s' > gmake[1]: *** [lit.site.cfg] Error 1 > > The relevant lines in test/Makefile: >

llvm-lit is already put into <output-tree>/bin by CMake. There is a CMake target called `llvm-lit` that will generate the <output-dir>/bin/llvm-lit script. If you built only a few specific llvm targets such as FileCheck, etc then you may need to run this lit target manually. If you just run "ninja" for example, or "ninja check-llvm", it's automatically

Hi, Using trunk llvm ; on powerpc (powerpc64/power7); trying to do a "gmake check", the sed bits in test/Makefile appear to be getting tripped up when trying to generate lit.site.cfg. I've started to hack at it, made a little bit of progress, but wonder if I'm just digging myself a hole. Highlights of what I've poked at are below.. Comments or thoughts? Thanks,

On Dec 10, 2013, at 11:26 AM, Alp Toker <alp at nuanti.com> wrote: > > On 10/12/2013 18:03, Jim Grosbach wrote: >>> That causes dissonance between what the compiler sees and what lit.py sees for no particularly good reason. One of the nice properties of lit tests is that they're also valid compiler inputs, so trailing slash is a bit unfortunate. >>> >>

Hi, Since I want to write tests with llvm-lit, I pulled the latest revision of LLVM from SVN HEAD and tried to run the following command (copied from http://llvm.org/docs/TestingGuide.html): $ ~/llvm/Debug+Asserts/bin/llvm-lit ~/llvm/test/Integer/BitCast.ll llvm-lit: lit.cfg:103: fatal: No site specific configuration available! Any ideas on why this happens? Thanks, Brice

So I manage to get clang's colored output through ninja simply by force (CMAKE_CXX_FLAGS=-fcolor-diagnostics), which isn't ideal (if I were to pipe ninja's output to a file it'd still have color escapes, etc) but it works. But I haven't found a similar solution for FileCheck & I'm wondering has anyone already solved this problem for themselves - if so, how? if not,