[PATCH] Initial clang-tidy architecture

[Daniel Jasper]

Sean: I agree with many of your points, but I don't agree that we have to
address them all beforehand. Some of them we don't even know just yet. But
I have started up the documentation and will update that with as much
information as I have.

Chandler: ping?


On Wed, Jun 5, 2013 at 8:15 PM, Sean Silva <silvas at purdue.edu> wrote:

>
>   Some really high-level thoughs:
>
>   One thing that I think has been neglected in the development of our
> other tools is what the end-user experience looks like. I feel like a bit
> of high-level "this is what I want the user experience/workflow to feel
> like" iteration at this stage could really have a significant payoff down
> the road. (side note: I love how clang-format is so easy to use, but it
> really has it easy since it doesn't need to fully parse and build AST's;
> clang-tidy has it a lot harder)
>
>   By "user experience/workflow" I mean a holistic end-to-end use case for
> the tool (such as our own, i.e. dogfooding). Especially:
>
>   * which commands they run to actually do stuff with the tool (and I
> don't mean in isolation; I mean a sequence of commands starting with `git
> clone`/`svn co`)
>   * what an external user's code would look like (where in their
> repository would they store extra checks of their own? how does this tie in
> with their build system? how to deal with backwards compatibility?).
>
>   I think we should have a clear vision of how we are going to dogfood
> this before committing any code, because honestly, if we don't use this,
> how can we expect others to? A couple questions off the top of my head:
>
>   * How is this going to integrate with our build system?
>   * Are we going to have pre-commit hooks? or a bot that automatically
> replies to patches on the mailing list/phabricator with issues flagged by
> clang-tidy?
>   * Is this something that a handful of people run periodically in
> batches, or is this something that we expect all developers to run on their
> code before committing?
>   * What fraction of our checks are idiosyncratic, and how many are
> generic and usable by other projects?
>
>   For example, I think it makes sense for llvm-specific checks to live in
> the LLVM source tree (*not* clang-tools-extra); e.g. our idiosyncratic
> include ordering. Then we get to feel what this actually feels like for an
> external project. Of course, as many have said, it makes a lot of sense to
> have a bunch of generally useful non-idiosyncratic checks that others can
> readily call upon in a config file, but we really need to consider
> idiosyncratic checks (i.e. C++ code using these APIs that is maintained in
> an external source tree).
>
>   Maybe we should build a pretotype (if you aren't familiar with that word
> you can ignore this sentence)? We have excellent technical implementation
> ability, so TBH actually building the tool isn't the hard part: we really
> ought to make sure we are building "the right it" before "building it
> right".
>
> http://llvm-reviews.chandlerc.com/D884
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130702/dc25307d/attachment.html>