[llvm-bugs] [Bug 40910] New: clang-format broken after lambda with return type template with boolean literal

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Feb 28 14:26:10 PST 2019


https://bugs.llvm.org/show_bug.cgi?id=40910

            Bug ID: 40910
           Summary: clang-format broken after lambda with return type
                    template with boolean literal
           Product: clang
           Version: 8.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Formatter
          Assignee: unassignedclangbugs at nondot.org
          Reporter: nikolaus at nikolaus-demmel.de
                CC: djasper at google.com, klimek at google.com,
                    llvm-bugs at lists.llvm.org

Clang format breaks on lambdas with return types that have literal booleans in
template arguments, e.g. 

    []() -> foo<true> { ; }();

The same works fine e.g. with integer literals. I tried version 7, 8, and
current version 9 from the Ubuntu Xenial apt repo and the behaviour is the same
everywhere. I narrowed it down to the following small test case:


template <bool>
using foo = void;
// works:
[]() -> foo<1> { ; }();
// broken:
[]() -> foo<true> { ; }();

namespace bar {
// broken:
auto foo{[]() -> foo<false> { ; }};
}  // namespace bar


I would expect clang-format (without additional options) to not change anything
here (which is the case if I replace 'true' / 'false' with e.g. '1', but the
actual result is as follows, which is particularly problematic in the presence
of namespaces as you can see:


template <bool>
using foo = void;
// works:
[]() -> foo<1> { ; }();
// broken:
[]() -> foo<true> { ; }
();

namespace bar {
// broken:
auto foo{[]() -> foo<false>{;
}  // namespace bar
}
;
}  // namespace bar

-- 
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/20190228/6edfb9ac/attachment.html>


More information about the llvm-bugs mailing list