Clang-format / clang-tidy VS plugin

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 like the idea, it would be nice to get new users for clang-tidy. I was thinking about the same thing some time ago, but didnt have much time to look closer.

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. 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

Yea, integrating options probably isn’t necessary for llvm developers, but i think it would be huge for driving adoption externally. Same with bundling the tool with the plugin so that it could be distributed standalone, perhaps even from the vs extensions gallery

Yea, integrating options probably isn’t necessary for llvm developers, but i think it would be huge for driving adoption externally. Same with bundling the tool with the plugin so that it could be distributed standalone, perhaps even from the vs extensions gallery

Getting the plugin into the extension gallery would definitely be nice. I’m not sure how much worth there is in keeping an options ui accurate, but if somebody else is willing to do the work, I say go for it :slight_smile:

Yea, integrating options probably isn't necessary for llvm developers, but
i think it would be *huge* for driving adoption externally. Same with
bundling the tool with the plugin so that it could be distributed
standalone, perhaps even from the vs extensions gallery

Getting the plugin into the extension gallery would definitely be nice. I'm
not sure how much worth there is in keeping an options ui accurate, but if
somebody else is willing to do the work, I say go for it :slight_smile:

+1

~Aaron

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

fwiw, the clang-format executable is bundled with the vs plugin
already, so the same could be done with clang-tidy. The interesting
thing (and the one that would require work) is exposing this stuff in
the ui in a good way.

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 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?

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

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.

So would the clang format plugin as it exists now (with style=file) and a UI VS editor component give you that?

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

It is not exactly windows ecosystem, it is IDE ecosystem.
Clion for example have something like this:
https://www.jetbrains.com/help/clion/2016.1/configuring-code-style.html

So it allows you to modify some basic settings and also import setting from file.

Having something like this would be awesome.

[Please reply *only* to the list and do not include my email directly
in the To: or Cc: of your reply; otherwise I will not see your reply.
Thanks.]

In article <CAAErz9h+_1_VzvzwewfR+_kOb=iLARs2QHxSN6GuVmZ0pQX7UQ@mail.gmail.com>,
    Zachary Turner via cfe-dev <cfe-dev@lists.llvm.org> writes:

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.

If you ship the executable with your plugin, then the options are
known at the time the plugin is packaged and you can generate the XML
at packaging time.

They are known, but if you ship an executable instead of link against a library, you can’t really share the code easily.

I don’t think we should store the config anywhere else but in .clang-format files, even on Windows. Otherwise people will need to configure it for each ide in use.
Building an editor component (like the XML editor) for .clang-format files seems fine, if somebody wants to do that. I think those options don’t change often enough to be worth lots of versioning effort.

Yea, I think I agree. The thing to do is put them in global settings as in the mockup and let that page be an editor for disk based files. The user selects a file and the ui is populated and making changes updates the backing file

> 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.

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?