[llvm-bugs] [Bug 48736] New: Ternary operators over multiple lines are always aligned, no option to treat them like regular continuation lines
via llvm-bugs
llvm-bugs at lists.llvm.org
Wed Jan 13 02:45:40 PST 2021
https://bugs.llvm.org/show_bug.cgi?id=48736
Bug ID: 48736
Summary: Ternary operators over multiple lines are always
aligned, no option to treat them like regular
continuation lines
Product: clang
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangbugs at nondot.org
Reporter: arnfranke at yahoo.com
CC: djasper at google.com, klimek at google.com,
llvm-bugs at lists.llvm.org
Created attachment 24375
--> https://bugs.llvm.org/attachment.cgi?id=24375&action=edit
Picture of absurd indentation when viewed on GitHub
For context, see https://github.com/godotengine/godot/pull/45136
It's currently not possible to have ternary continuation lines use the normal
continuation behavior. Clang-format insists on aligning ternary continuation
lines such that both of the possible values are aligned. In some cases this
leads to absurd code formatting. In the snippet I pointed out on GitHub, the
code doesn't start until column 61 (or column 121 for anyone using 8-size tabs
or viewing on GitHub) and continues for 60 more characters (for anyone using
8-size tabs, this means that the code doesn't end until column 181).
I would like to instead use the normal continuation line behavior, with the
"ContinuationIndentWidth" setting, so that ternary continuation lines are
always a fixed amount of width from the start of the main line just as other
continuation lines already do. Perhaps there should be a setting called
something like "AlignTernaryOperators" with a default setting of true, and then
I could set this to false to get the desired behavior (in the linked snippet
this would mean the line starts at column 25, or 49 for 8-size tabs).
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210113/c7a25093/attachment-0001.html>
More information about the llvm-bugs
mailing list