[cfe-dev] Clang-format / clang-tidy VS plugin

[Alexander Kornienko via cfe-dev]

In this particular case incremental approach seems reasonable to me, since
the whole plugin might be too large to review as a single patch.

On Tue, Aug 23, 2016 at 6:32 PM, Zachary Turner <zturner at google.com> wrote:

> What would be the best way to go about upstreaming such an extension?  For
> example, I am pretty close to having a complete UI for editing clang-tidy
> configuration files and visualizing which checks are enabled.  But nothing
> actually *runs* clang-tidy or applies fixes yet.  So ultimately it doesn't
> yet support the primary feature.  On the other hand, incremental
> development and all that.  Is it ok to commit what I have as a work in
> progress and then iterate on it until it's finished?  Or should I wait
> until it's complete before trying to upstream?
>
> On Fri, Aug 19, 2016 at 6:48 AM Alexander Kornienko <alexfh at google.com>
> wrote:
>
>> On Mon, Aug 15, 2016 at 12:14 AM, Aaron Ballman via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>> On Fri, Aug 12, 2016 at 6:58 PM, Zachary Turner via cfe-dev
>>> <cfe-dev at lists.llvm.org> wrote:
>>> > I was thinking about some ways to improve clang-format, and possibly
>>> even
>>> > add clang-tidy to the list of things our VS plugin supports.  Perhaps
>>> even
>>> > merge them into a single plugin.  But you know, I'm a windows person,
>>> and I
>>> > want a UI.  I don't want to just click a button and have it use some
>>> > settings that are on disk that I edited by hand, I'd like to be able
>>> to edit
>>> > the settings themselves through a nice UI, like everything in VS.
>>> >
>>> > This is kind of difficult if the plugin shells out to an external tool
>>> > without linking against it, because it doesn't have any knowledge of
>>> what
>>> > specific options and features the version it's calling might support in
>>> > order to build the appropriate UI to set them.  On the other hand, if
>>> it
>>> > links against the tool, this all becomes very easy, because the plugin
>>> can
>>> > share types and data structures with the tool itself.  And it also
>>> means
>>> > that someone could download the plugin without installing LLVM, as a
>>> > standalone tool, greatly reducing the barrier to entry for people
>>> wanting to
>>> > try out the tool.
>>> >
>>> > Here's a quick mockup of what my ideal UI would look like and what I
>>> have in
>>> > mind: http://imgur.com/a/p3XBv
>>> >
>>> > But again, it's hard to maintain this kind of thing if the VS plugin
>>> has to
>>> > rely on an external tool to do the formatting, since it would have to
>>> know
>>> > about every possible set of options for every version as the software
>>> > improves.  So in order to do this this way, we'd need to probably build
>>> > clang-format and/or clang-tidy as a DLL and bundle them with the
>>> plugin,
>>> > which could link against it.
>>> >
>>> > Not really asking anyone else to do the work so much as I am asking if
>>> > people think this would be cool and/or something they'd like to see.
>>> > Personally I think it would be a great way to get clang-format and
>>> > clang-tidy onto more peoples' systems, particularly those people who
>>> are not
>>> > currently using clang on Windows, since this would be standalone and
>>> work
>>> > out of the box while providing a familiar user interface to what
>>> people are
>>> > used to.
>>> >
>>> > Thoughts?
>>>
>>> I would *love* to see clang-tidy exposed as a plugin within Visual
>>> Studio.
>>
>>
>> I guess, it should be easy to add it as an external tool. The question is
>> whether VS supports presenting output of external tools as diagnostics?
>> Otherwise, a real VS extension would be needed.
>>
>>
>>> The existing clang-format integration we already have is
>>> basically the only reason I use clang-format -- I don't want to drop
>>> into a command line from my editor unless I absolutely have to, so
>>> integrating clang-tidy makes it far more likely to check code early
>>> and often. The tight integration of the options with the editor would
>>> be really nice, but not critical for my particular usage (the defaults
>>> for both tools are fine for my needs).
>>>
>>> ~Aaron
>>>
>>> >
>>> > _______________________________________________
>>> > cfe-dev mailing list
>>> > cfe-dev at lists.llvm.org
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>> >
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160824/2352d583/attachment.html>