I'm sorry, but now you are missing the files from the review, I think you diffing against your own commits and not commit that are in the repo. This makes the review very difficult to understand.
Jan 3 2021
we don't commit with failing tests so lets understand why it fails.
by and large, this looks pretty good to me..lets have some other comment
You need to have these conversations by adding new unit tests that prove your point, I highly doubt I'll personally be willing to accept any revision without more unit tests than this one line change
Jan 2 2021
I think we are missing some clarity in this bug as to what the actual problem is, I do agree the test looks wrong,
Jan 1 2021
Dec 31 2020
ok so this looks ok, but before we commit can we have a discussion about why you think it fails for the comment case?
Take the following example:
I think if you think you have a bug that you log it in the bug tracker and we track it with this issue.
Dec 30 2020
Address review comments
Dec 29 2020
@mitchell-stellar do you plan to bring this back?
I like what you are suggesting, do you think BasedOnStyle: File is the best terminology as the term File is used elsewhere to mean read from the .clang_format file, how about
Dec 28 2020
Addressing additional usecase found issues in C# tests too
Dec 27 2020
I'm a little confused why this is needed as clang-format always read up the directory tree until it see a .clang-format file, perhaps I don't quite understand the use case. Can't you just have a different .clang-format in the subdirectory?
Thank you for this patch, a few process issues.
Dec 26 2020
This is the closest I could find thus far http://bitsavers.informatik.uni-stuttgart.de/pdf/chromatics/CGC_7900_C_Programmers_Manual_Mar82.pdf
Dec 24 2020
Dec 23 2020
I don't have any major issues with this other than it makes Format.h a bit more ugly. (there are more ugly and harder to understand pieces of code than this change!)
We should probably check the docs/tools/dump_format_style.py still works
Dec 22 2020
LGTM now. I tried to find other cases where this change may change the behaviour but couldn't. Have you tried applying to some bigger repo and see what you get? The best would be a repo with SpaceAfterCStyleCast=true.
remove = and ~ cases
remove unrelated change
Dec 21 2020
Dec 19 2020
Thanks for making the changes, this LGTM
With my maintainer-of-Support/JSON hat on, I don't like the idea of these features being shoehorned into the library to make clang-format an incrementally more featureful JSON formatter. They're likely to lead to a lot of conceptual+implementation+API complexity in a library that solves its primary use cases quite well and simply.
Dec 18 2020
And what happens when reformatting only a part of a JSON? Should there be some tests for that?
Dec 17 2020
Add additional unit test
Dec 16 2020
I'd like to see a test with braces inside the try (intoducing scope), just to verify it doesn't break.
Nit: Please just separate your test from old test, apart from that I think its fine
Dec 15 2020
I don't like seeing users having to use `// clang-format off```
not that rare it seems
Aside: Would you be prepared to take a look at D34225: [clang-format] Teach clang-format how to handle C++ coroutines which is pretty much been abandoned, and see if there is anything there that might help the co_routinues support?
I generally don't have the same aversion to new options than others have, but can you point out a style guide that might want this option. (that is kind of the process)
Dec 14 2020
This didn't really address the comments, what is the point of the maximum? what if the maximum is > the ColumnLimit?
Dec 13 2020
We should have the same examples added to the unit tests so we know they are correct (and stay correct)
Dec 12 2020
Dec 10 2020
Dec 9 2020
add support for additional _Pragma
Dec 8 2020
And where do I do that? Also I did not think I would not have a chance of getting the access so early.
Dec 7 2020
Could we consider dropping the maximum?
Can I assume you need someone to land this for you?
Yes I do. But I have a question, my last change is commited in your name, that means git blame would blame it on you, right?
You can set me as author:
Björn Schäpers <firstname.lastname@example.org>
My Github Account is also called HazardyKnusperkeks.
The process is that you add (https://llvm.org/docs/Contributing.html)
Patch By: HazardyKnusperkeks
to the commit message if the user doesn't have commit access, if you want your name against the blame then I recommend applying for commit access yourself.
That is incorrect and does not represent the nowadays reality, i suggest that you look up the docs.
let me know if you still want me to land this
I'm a little confused between BestFit and Compact
@catskul I'm really sorry this disappeared into the ether because it was missing the project and any real reviewers, I tend to go back now and again and do a search for "Lost" clang format reviews and stumbled on this one, hopefully this will bring it to the fore if you are still interested
Looks almost there, just a few nits really
What does the behavior goes wrong mean? why can't it be left aligned?