- User Since
- Apr 25 2017, 12:43 AM (129 w, 11 h)
Aug 28 2019
Jun 11 2019
Jun 7 2019
Jun 6 2019
May 29 2019
- Fix NamespaceEndCommentsFixerTest to match LLVM indent style
May 28 2019
- Adapt styles search path to platform conventions
- Allow customizing search path at compile time
- Allow overriding search path at runtime through CLANG_FORMAT_STYLES_PATH env variable
May 24 2019
May 23 2019
Ah, wow, I see what confused me now:
In the fixNamespaceEndComment tests you use an indent that clang-format would not produce. Can you please fix that, otherwise I find this super confusing :)
May 22 2019
Actually, looking at all the other options, the same is true for all other macro kind of macros (NamespaceMacros...).
Regarding variable/setting names, one issue I see is that these macros are not really type names IMO : the macro name is just part of the type (like a template), and its invocation is a type declaration. So maybe renaming to Typedecl or something like this would be slightly more representative.
The patch goal is indeed to indent the content of namespace-macro blocks like the content of any 'regular' namespace. So it should look like the content of a namespace, possibly depending on the choose style options. To sumarize, here is a detailed summary of the observable differences between macros vs normal namespace.
May 17 2019
Nov 27 2018
Oct 29 2018
Oct 4 2018
Oct 3 2018
Oct 2 2018
Sep 25 2018
Sep 4 2018
clang-format does indeed support .clang-format, which is great for *isolated* projects, and which is not affected by this patch.
Aug 1 2018
This has been stale for a while now. Last comment indicate this is not the right approach, but some prototyping has been done a more generic approach, with no timeline.
I understand this, but in the meantime the problem is still there, with no solution at the moment...
Jul 31 2018
- I choose not to add an option to enable this behavior, as I think of it as just another way clang-format can (better) format the code; but I can one if needed
- Currently, it relies on another patch (D32478), which supports aligning the wrapped operator slightly differently. If/since that other patch does not seem to make it, I can change this patch to either do the alignment in this specific case (e.g. for wrapped ternary operator only) or to keep the 'default' behavior of clang-format (e.g. the wrapped colon would be aligned with the first condition):
Jun 14 2018
Add missing block, for consistency
Jun 12 2018
Jun 11 2018
Jun 8 2018
Would it be acceptable to introduce an option to allow enabling this behavior?
I mean would it have a chance of being integrated, or must I keep maintaining a fork of clang-format...
May 17 2018
Address review comments
May 16 2018
Rebase on latest master
Rebase on latest master
Rebase on latest master & address review comments
Address review comment & rebase
Mar 22 2018
You are right, I did not mean it would help with the handling of these macros; but it may be related on the configuration-side of things : adding an option for listing these macros may hit the same limitation, and the same mean of storing (in the code) the list of these macros may be used.
A generic (or at least extandable) approach to specifying macro behaviors was introduced here: https://reviews.llvm.org/D33440
Mar 13 2018
Mar 9 2018
Mar 5 2018
Mar 2 2018
Also double-checked with Richard Smith and he agrees that the current behavior is preferable. For comma and plus this doesn't seem overly important, but making it:aaaaaaaaaa(bbbbbbbbb + ccccccccccc * ddddddddd);
seems really bad to him as this suggests that we are adding both ccccccccccc and ddddddddd.aaaaaaaaaa(bbbbbbbbb + ccccccccccc * ddddddddd);
If people don't care about this case, we might as well merge this :-) Just kidding.
Mar 1 2018
Change options values to No/MultiLine/Yes.