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

Zachary Turner via cfe-dev cfe-dev at lists.llvm.org
Tue Aug 16 20:49:57 PDT 2016

Pretty much this. Having a clang format file checked in is a great way to
share settings among a team. It also unlocks the full power of the tool,
whereas a UI may only sometimes expose a subset of that.

But any time someone has to manually edit a file, or go online to look up
documentation and figure out syntax and rules or whatnot, it's going to be
a detractor.

For better or worse, that's just the Windows ecosystem..

An integration that used the .clang-format files as the underlying
serialization format but exposed the resulting set of options through a
rich UI would be the best of both worlds.

I don't know how easy this will be , or even if it's possible. The visual
studio project system expects settings to be defined at the project level,
and at the file level every setting can be either inherited (default) or
overridden. That doesn't line up perfectly with the clang format model of
overriding at a directory level. If someone changes a setting at the
project level, what does that mean for the style file? Same goes for
modifying a setting at the file level.

We could probably solve these problems by giving clang format the ability
to override settings per file, but that's obviously more work.

Now I remember why i put the settings in global options in the mockup :-/.
It's hard at the project level
On Tue, Aug 16, 2016 at 8:26 PM Michael Lewis <don.apoch at gmail.com> wrote:

> The Windows lifestyle, for what it's worth, would prefer to have a GUI for
> modifying the .clang-format settings but still serialize them as always.
> This way you get the accessibility without losing the strengths of having
> a versionable file on disk.
> Speaking as a virtually all-Windows dev, I would be exceedingly happy to
> get better clang-format support in VS. Writing a VS plugin isn't hard, for
> what it's worth, and can totally offer a fully dynamic editor for the
> settings stored on disk. I can definitely say that such a plugin would be
> very popular even among programmers who don't build (primarily) with clang.
> - Mike
> On Aug 16, 2016 8:05 PM, "Manuel Klimek via cfe-dev" <
> cfe-dev at lists.llvm.org> wrote:
>> On Tue, Aug 16, 2016, 10:49 PM Zachary Turner via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>> That is one idea that I considered, but from what I understand of how to
>>> implement options UI in Visual Studio (I have never actually done this, but
>>> looked at it for an hour or so once upon a time) the options and values
>>> need to be statically defined in order to create the UI property sheet.  ie
>>> you can't build one of these sheets dynamically, because the UI is
>>> generated when Visual Studio loads your extension by reading some XML.
>>> It's possible my understanding is wrong though.
>>> I agree that per-project and per-file settings would be nice.  I'll have
>>> to think about this some more though, as you would want a tight integration
>>> with what people normally expect with the project system, such as being
>>> able to override settings on a per file basis.  This also means figuring
>>> out how to make this interoperate (if at all) with existing .clang-format
>>> settings files on disk.
>> That's why we have the files on disk. Do you think people on Windows
>> would not want to just check in a .clang-format file and use style=file?
>>> On Tue, Aug 16, 2016 at 12:41 PM Yury Mikhaylov <
>>> yury.mikhaylov at gmail.com> wrote:
>>>> Can't we just ask clang-format to dump all options that its parser
>>>> understands and use that info to populate property sheet in MSVC? Something
>>>> similar to what -dump-config does now.
>>>> I have also noticed that your mock-up shows the prop sheet in the
>>>> system-wide settings. Won't it be better to keep them on per-project basis?
>>>> Maybe even parse/regenerate .clang-format file in the project folder to
>>>> allow versioning?
>>>> - Yury
>>>> On Fri, Aug 12, 2016 at 3: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?
>>>>> _______________________________________________
>>>>> 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
>> _______________________________________________
>> 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/20160817/d0126f6c/attachment.html>

More information about the cfe-dev mailing list