- User Since
- Aug 18 2015, 2:16 AM (213 w, 5 d)
wrong patch file
I assume the intention was that users could have DisableFormat=true and SortIncludes=true when they want to sort the includes but not perform any additional formatting in the code.
Fri, Sep 20
Thu, Sep 19
Wed, Sep 18
Tue, Sep 17
I should have known it was more involved.
when/if you commit can you abandon D6833: Clang-format: Braces Indent Style Whitesmith
Thank you for this patch
Mon, Sep 16
Thu, Sep 12
Yes, it would be good if it is landed. And can I know the procedure for getting commit access
Does this need landing? given that you have a number of patches in flight perhaps it would be good to request commit access
Tue, Sep 10
Thank you for this patch, i've seen a number of PRs raise to this effect.. this looks to be a great start in this area
Sat, Sep 7
This LGTM, just some minor Nits
Mon, Sep 2
but perhaps I'm really just agreeing to @sammccall 's suggestion of "-style=<filename>" which kind of feels sufficient to me..
I am not opposed to this idea, I actually think this has some mileage based on a use case I've encountered:
Mon, Aug 26
Aug 23 2019
Aug 22 2019
Aug 18 2019
This patch is needs rebasing
Aug 16 2019
Aug 11 2019
Aug 10 2019
Aug 5 2019
Assuming this works and the other unit tests don't show issues then this LGTM. Please consider running this on your NetBSD code base before committing, if possible please also run on clang code based to ensure existing sorted headers aren't sorted unexpectedly.
Jul 24 2019
We don't normally commit a failing test alone, otherwise the build machines will be broken until it gets fixed.. just add this test with your fix.
Jul 15 2019
I appreciate what you've done to make this patch less duplicated code..but now you've almost got to the point where being able to control it all via configuration.
Jul 14 2019
There also seems like alot of duplication between the existing sortCppIncludes
Do you think there is anything about this algorithm that could be parameterized so that other projects could utilize it? I guess its not completely clear how this differs from just using the IncludeCategories?
Jul 10 2019
Jun 25 2019
It was more about not having time to pursue it at this time.. I didn't feel I should hog the PR if someone else wanted to take a look.
Jun 20 2019
Jun 13 2019
Jun 12 2019
Nit: if you going for "OnePerLine" in the name rather than "Break" can you keep it consistent with ConstructorInitializerAllOnOneLineOrOnePerLine and put the type first and then the operation i.e. BitFieldOnePerLine (this will help keep all BitField options together if there are ever more than one), I also think either don't use Decl at all or use the full word Declarations as in AlignConsecutiveDeclarations , AlwaysBreakTemplateDeclarations etc
Jun 11 2019
mark sure you mark off the comments as you consider them done.
Jun 10 2019
Jun 9 2019
You need to add a unit test in clang/unittests
May 21 2019
Just a passing comment, Is this:
May 15 2019
May 14 2019
please simply remove line 249
May 10 2019
@klimek responded via the mailing list
When I spoke with one of the code owners, they seemed to have a problem accepting this review based on there not being a general description/understanding of how this algorithm works.
May 3 2019
May 1 2019
Thanks for the patch, thanks also for changing to https as I believe this was a change suggested in clang tidy docs too
Thanks for the patch, is this case only limited to *<tab>
Did this case some issue? Does this fix something if so can we add a test, because maybe the line isn't needed
Apr 27 2019
Apr 23 2019
This looks logical to me, seems to fit with what `WhitespaceManager::appendNewlineText` is doing
Apr 18 2019
Abandoning in favor of D60853: clang-format converts a keyword macro definition to a macro function
Apr 17 2019
@klimek one possible solution to this might be to replace the "keyword" back to an identifier in a '#define <keywoord>' scenario
Apr 15 2019
Apr 14 2019
use endsWith() as it ignored comments
Apr 11 2019
I suppose we could keep the names and directory structure and just change the namespace. That would just be a special case in the scripts. Haven't looked into it yet, but will do so as soon as I can.
Isn't that matching done on strings? I.e. is there difference between -llvm-* and -ll* ?
I agree and would be happy with the change if it would only change the line-filtered workflow, but this afaict (unless I'm missing something :) will also affect the workflow where the provided range is 0-length range, which has an implicit "format stuff around this" request from the user inside it. I'd be happy with a patch that differentiates these two sides.
are we supporting "-llvm-*" in existing .clang-tidy files?
Apr 9 2019
Apr 8 2019
Addressing review comments
Reduce test cases
@ownenpan might be worth checking with @reuk who has been adding some options for the JUCE style guide and looking at the JUCE code it seems this style might match their style.