[PATCH] Initial clang-tidy architecture
djasper at google.com
Tue Jul 2 00:05:48 PDT 2013
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.
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
> * 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits