[PATCH] PPCallbacksTest expansion - part 1

John Thompson john.thompson.jtsoftware at gmail.com
Mon Nov 18 09:45:37 PST 2013


Yeah, Sean's too generous in giving away credit, the tool was his idea.

What happened was that I needed a small change to the PPCallbacks
conditional callbacks to give them the end result of the conditional
expression, so I did that and checked it in.  Someone (I can't find the
original comment, but I think it was Argyrios) commented that it would be
nice if someone extended the unit test for PPCallbacks, as the current
version only covered the include mechanism.  I said I would do it shortly,
but wanting to finish my modularize work, it turned out to take a while
before I got to it.  I extented the original test, but with just the
framework and a couple of initial tests, then Sean suggested making it a
tool and using FileCheck for the PPCallback tests.  Actually, the thought
did occur to me to do it this way originally (but without YAML), but I
didn't think writing a new executable for the test would fly with the
community, so I went for enhancing the orginal test.  I can't say I was
happy to throw away that work, but when Sean suggested the new direction, I
was happy to do something that might be useful for someone for other
purposes.  I pushed back a bit about the YAML, but I'm glad I got to learn
a little about it, and from a first cut I discarded, about the YAML I/O
library as well.

With respect to including pp-trace into clang/tools, I think the recent
discussion about the "extra" build being separate probably pertains to
that.  (If you didn't see it, search cfe-commits for the subject "Re:
[llvm] r193350 - Reverting my r193344 checkin due to build breakage" for
the discussion I inadvertantly and embarassingly kicked off with my
error.)  I think it would be nice to have the "extra" tools in the main
clang tree, but I don't really have any strong feelings either way, as it's
not very hard to check it out and build it separately.  However, I do have
a concern about people not knowing about these tools.  (I only learned
about them when someone suggested to me using one or two of them.)  Some of
the tools have documentation, but after a quick look on the clang website,
I couldn't find it, so I think the clang docs could to be updated with a
mention of them and links to more info.  I'm not sure how this should be,
since the extra docs are in the separate extra tree.

Regarding adding tests to clang/test that depend on pp-trace, I see your
point that it would make sense to have tests for something in clang in the
clang tree.  I suppose new tests for new stuff in PPCallbacks could just be
added to the pp-trace tests.

Note that while debugging the callback tests for pragmas, I noticed that
there seems to be a number of pragmas not covered by PPCallbacks.  I should
probably add a fixme comment to PPCallbacks.h.

-John



On Sun, Nov 17, 2013 at 12:01 AM, Kim Gräsman <kim.grasman at gmail.com> wrote:

> Hi Sean,
>
> On Sun, Nov 17, 2013 at 8:55 AM, Sean Silva <silvas at purdue.edu> wrote:
> >>
> >> It'll be difficult to use pp-trace for these tests, though, as it's in
> >> clang-tools-extra. Was there a plan to get it into clang/tools?
> >
> > If it would be useful for writing test in clang/, then I think it makes
> > sense to move it. Why don't you try emailing cfe-dev with some example
> tests
> > you would like to add?
>
> I don't have any particular needs, but I thought John's original
> motivation (the core of this patch) was to add tests around some
> changes of his to PPCallbacks. He started out with unit tests, and
> then you suggested a FileCheck-compatible tool, pp-trace was born,
> everybody was happy, and maybe we lost track of the original problem?
> :-)
>
> - Kim
>



-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131118/6631a57f/attachment.html>


More information about the cfe-commits mailing list