This is an archive of the discontinued LLVM Phabricator instance.

Added new options to ClangFormat VSIX package.
ClosedPublic

Authored by curdeius on Oct 8 2015, 3:28 AM.

Details

Summary

Added new options to ClangFormat VSIX package:

  • fallback-style
  • assume-filename
  • sort-includes.

Changed version to 1.1 (otherwise one couldn't update).

Fixed clang-format escaping of XML reserved characters.

Diff Detail

Event Timeline

curdeius updated this revision to Diff 36840.Oct 8 2015, 3:28 AM
curdeius retitled this revision from to Added new options to ClangFormat VSIX package..
curdeius updated this object.
curdeius added a reviewer: djasper.
curdeius set the repository for this revision to rL LLVM.Oct 8 2015, 3:28 AM
djasper edited reviewers, added: klimek, hans; removed: djasper.Oct 8 2015, 3:32 AM
djasper added subscribers: cfe-commits, djasper.

Please always add cfe-commits as "subscriber" so that the email also goes to the list.

curdeius updated this revision to Diff 36849.Oct 8 2015, 6:08 AM

Escape XML-reserved characters.

curdeius updated this object.Oct 8 2015, 6:09 AM
curdeius updated this revision to Diff 37081.Oct 12 2015, 1:13 AM

Fix description formatting.

klimek added inline comments.Oct 12 2015, 1:24 AM
lib/Driver/Tools.cpp
2356 ↗(On Diff #37081)

Seems unrelated?

tools/clang-format/ClangFormat.cpp
229

For XML, we should only need "<" and "&". Everything else is just important in a context introduced by "<" or "&".
The problem with include-sorting is that we'll now need to fully support utf8 input (well, any encoding, to be precise).
The best way is probably to escape all code points that are outside the ascii range. The problem I see is that we have no idea what encoding the file is in, so I have no clue how we can really resolve this.

curdeius added inline comments.Oct 12 2015, 1:41 AM
lib/Driver/Tools.cpp
2356 ↗(On Diff #37081)

Oups, I've made a mistake when updating the revision and pulled in the changes from master.
I'll correct this.

tools/clang-format/ClangFormat.cpp
229

Ok. I'll cut it down to the necessary minimum ('<', '&').
Anyway, I thing it's more urgent to fix the include sorting containing open brackets and later work on UTF-8 support.

klimek added inline comments.Oct 12 2015, 1:47 AM
tools/clang-format/ClangFormat.cpp
229

Agreed. Can you please add a FIXME though:
FIXME: When we sort includes, we need to make sure the stream is correct
utf-8.

curdeius updated this revision to Diff 37086.Oct 12 2015, 2:20 AM

Escape only '<' and '&'.
Remove unrelated changes from the revision.

curdeius updated this revision to Diff 37087.Oct 12 2015, 2:23 AM
curdeius marked 2 inline comments as done.

Add FIXME comment.

curdeius marked 3 inline comments as done.Oct 12 2015, 2:26 AM

Applied suggestions from comments.

klimek added inline comments.Oct 12 2015, 2:34 AM
tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
261

Don't we need " escaping for assumeFilename? (or do we consider that an error? in which case, would we want to make that an error?)

curdeius added inline comments.Oct 12 2015, 2:39 AM
tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
261

Well, quotes (") are not allowed as a part of a file name on Windows.
What we could do is to strip surrounding quotes if the user added them in order not to add them twice.

klimek added inline comments.Oct 12 2015, 2:55 AM
tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
261

Oh, I didn't know that.
My main concern is what happens when the user (accidentally) adds quotes (for example, unbalanced) and messes up the command line in a way that leads to a super hard to diagnose problem

curdeius added inline comments.Oct 12 2015, 3:15 AM
tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
261

Hmm, you're right, we should do something with that.
Either:

  • escape all quotes (but then the errors will be silent and user will not know that something bad happens)
  • or to give an error message somehow, e.g. by using a custom TypeConverter for AssumeFilename option that will check for the existence of quotes.
klimek added inline comments.Oct 12 2015, 3:34 AM
tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
261

I'd vote for the latter, if possible.

curdeius updated this revision to Diff 37115.Oct 12 2015, 8:11 AM

Add option converters for filenames (prohibiting quotes) and styles (giving a list of predefined styles).

curdeius marked 5 inline comments as done.Oct 12 2015, 8:13 AM

Assume-Filename option will now give an error when there are quotes in the filename.

+aaron, as token Windows Wizard

+rnk, as I was told you might know people who are in a good position to review MS specific stuff (perhaps engineers from MS might be able to help here? :)

aaron.ballman edited edge metadata.Oct 13 2015, 7:27 AM

Generally looks good to me, with a few small nits.

tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
56

Can we just return directly here instead of storing in a local?

81

Why is 'file' now lowercased?

115

I see now why this is being used, but it took a lot of context from review comments to understand. Can you please put in a more descriptive comment about why we're checking for quotes, despite them being invalid filename characters on Windows?

curdeius added inline comments.Oct 13 2015, 7:39 AM
tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
56

Hmm, yes, we can.

81

I wanted to be consistent with clang-format --help. Besides, lowercase styles (file, none) are somewhat special and it's nice to have them stand out, IMO.

115

OK, will do.

aaron.ballman added inline comments.Oct 13 2015, 7:40 AM
tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
81

That seems reasonable to me. Just making sure it wasn't a drive-by unintended change, or had some weird semantic meaning in MSVC.

curdeius updated this revision to Diff 37253.Oct 13 2015, 8:04 AM
curdeius edited edge metadata.

Applied Aaron's comments. Removed unused using.

curdeius marked 7 inline comments as done.Oct 13 2015, 8:06 AM

Applied comments and done some minor clean up.

We're waiting for Reid to find somebody who is good at reviewing this in detail.
Sorry it takes a while, so far we don't have enough trusted Windows experts in the community :(

While we are waiting, submitted the changes to ClangFormat.cpp in r250440. Thank you!

rnk added a reviewer: zturner.Oct 15 2015, 2:04 PM
rnk edited edge metadata.

We're waiting for Reid to find somebody who is good at reviewing this in detail.
Sorry it takes a while, so far we don't have enough trusted Windows experts in the community :(

Oops, I didn't know that. Zach knows C#, but I don't think any of us are VSIX experts.

zturner edited edge metadata.Oct 15 2015, 2:51 PM

No obvious problems, mostly just style issues. Feel free to consider them optional.

tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
38

How about an enum instead?

private enum Style {
    File,
    Chromium,
    Google,
    LLVM,
    Mozilla,
    Webkit
}
private Style style;

Then change the StyleConverter to just convert the enum value to its corresponding string representation?

42–47

This would all go away

56

This becomes return new StandardValuesCollection(Enum.GetValues(typeof(Style)))

61–64

This becomes sourceType == typeof(Style) || base.CanConvertFrom(context, sourceType)

69–73

This becomes

Style s = value as Style;
if (value == null)
    return base.ConvertFrom(context, culture, value);
return value.ToString();

(I think, I can't tell what the source and destination type are supposed to be here)

92

Now you can return an enum here instead of a string

115

Wouldn't it be better to just return false from CanConvertFrom if the filename contains quotes? Then you can assert in this function that it does not contain quotes?

136–143

Same comment as before, but use the enum.s I guess you would need to make None one of the actual style enum values, but remove it before returning the list in the other StyleConverter.

331–347

Maybe you could use properties instead of functions.

zturner accepted this revision.Oct 15 2015, 5:38 PM
zturner edited edge metadata.
This revision is now accepted and ready to land.Oct 15 2015, 5:38 PM

Hi Zachary, just to answer your comments. I have done it on purpose not to use enum, because clang-format style can be actually a JSON string, e.g. {BasedOnStyle: "LLVM", IndentWidth: 4}, so it wouldn't translate into an enum (to my knowledge at least). Besides, I would like to have the possibility not to add a new enum value if there is a new style in clang-format.
Please correct me if I'm wrong about enums.

tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
115

Well, in CanConvertFrom, the sourceType parameter is a Type and not the value given by the user, so no, we cannot do this.

Hi Zachary, just to answer your comments. I have done it on purpose not to use enum, because clang-format style can be actually a JSON string, e.g. {BasedOnStyle: "LLVM", IndentWidth: 4}, so it wouldn't translate into an enum (to my knowledge at least). Besides, I would like to have the possibility not to add a new enum value if there is a new style in clang-format.
Please correct me if I'm wrong about enums.

Where is the code in the CL that handles extracting that value from a JSON string? Because it looks like you're just building an array list of the trivial non-JSON style names, so why couldn't that be an enum? I don't know mucha bout clang-format, but looking at the comments it seems like the JSON only comes into play when you're reading a .clang-format file, and in that case the value of the enum would be Style.File (until you finish reading that, at which case you set it to Style.LLVM etc).

I'm also not sure what advantage you get by not having to add an enum if there is a new style? You have to change the code either way, and by not using an enum you are likely to miss some of the places in the code that manipulate or process the style since you're bypassing the type system.

Where is the code in the CL that handles extracting that value from a JSON string? Because it looks like you're just building an array list of the trivial non-JSON style names, so why couldn't that be an enum? I don't know mucha bout clang-format, but looking at the comments it seems like the JSON only comes into play when you're reading a .clang-format file, and in that case the value of the enum would be Style.File (until you finish reading that, at which case you set it to Style.LLVM etc).

The Style option is actually passed to clang-format -style parameter and it's clang-format that parses it. It can be a predefined type (one of: 'none', 'file', 'LLVM', etc.) or a JSON (or JSON-like?) string.

I'm also not sure what advantage you get by not having to add an enum if there is a new style? You have to change the code either way, and by not using an enum you are likely to miss some of the places in the code that manipulate or process the style since you're bypassing the type system.

I wanted to say that it would be better if the user didn't have to wait until the VSIX plugins gets updated after a new style is added to clang-format.

Oh I see. Makes sense then.

curdeius closed this revision.Oct 19 2015, 3:10 AM
hans edited edge metadata.Oct 19 2015, 9:45 AM

This is now part of the latest snapshot at http://llvm.org/builds/
Seems to work :-)

I had to dig around a bit to figure out where these settings are actually exposed. Should we mention that in the documentation somewhere? Actually, do we even have any documentation for this plugin?