- User Since
- Apr 25 2017, 12:43 AM (206 w, 6 d)
Aug 11 2020
Could this also be causing https://bugs.llvm.org/show_bug.cgi?id=33896 ?
Jun 24 2020
May 28 2020
Regarding ?:, this is definitely not considered, and should be relatively easy to handle.
Indeed, I saw the emails, but I didn't have time to check or investigate the issues.
May 26 2020
May 22 2020
May 15 2020
Fix random crash on windows
May 6 2020
Still no chance getting a windows or s390x machine, but i could reproduce the/a problem systematically on linux by enabling sanitizer.
In this case, initializing ConditionalsLevel to 0 in constructor does index fix this issue (and initializing to 1 ensures the issue happens, though not in "regular" linux build).
Apr 24 2020
Thanks for trying the patch, too bad it does not work...
I will see how to get the required setup/env, but it will probably take some time (esp. in the current situation).
Apr 23 2020
Apr 22 2020
Nov 19 2019
Nov 15 2019
Nov 14 2019
Oct 25 2019
Rebase on top of D50078
Implement a fallback to regularly indented alignment when the question mark is wrapped.
Oct 24 2019
Sorry, I struggled a bit with git & phabricator, and ended up uploading non-working code :-/
Fix earlier error in patch upload.
Fix corner in previous rebase
Oct 23 2019
Rebased on master, integrating required code from https://reviews.llvm.org/D32478
Oct 17 2019
This actually depends on another Diff : https://reviews.llvm.org/D32478
That other change introduces the ability to "unindent operator", which is required here; however, it also changes AlignOperands to have more than 2 modes, which does not seem to be acceptable.
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...