[llvm-bugs] [Bug 33135] New: Please add the component clangd in the clang-tools-extra product
https://bugs.llvm.org/show_bug.cgi?id=33135 Bug ID: 33135 Summary: Please add the component clangd in the clang-tools-extra product Product: Bugzilla Admin Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Products Assignee: unassignedb...@nondot.org Reporter: malape...@gmail.com CC: llvm-bugs@lists.llvm.org The title says most of it :) Clangd is a tool part of clang-tools-extra. As people use it and test it, it will be useful to be able to log bugs under this component. Thank you! -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32950] LLD COFF unreferenced imports still added
https://bugs.llvm.org/show_bug.cgi?id=32950 Ignat changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33134] New: Invalid LDR instruction with XZR
https://bugs.llvm.org/show_bug.cgi?id=33134 Bug ID: 33134 Summary: Invalid LDR instruction with XZR Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: kongy@gmail.com CC: llvm-bugs@lists.llvm.org Constant 0 is optimized to XZR in an ASM load instruction, which is illegal. $ llc ldr0_aarch64.ll :1:11: error: invalid operand for instruction ldr x8, [xzr] ^ note: !srcloc = 67 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33133] New: UBSan misses check for "negative_value << 0"
https://bugs.llvm.org/show_bug.cgi?id=33133
Bug ID: 33133
Summary: UBSan misses check for "negative_value << 0"
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: libclang
Assignee: unassignedclangb...@nondot.org
Reporter: babo...@gmail.com
CC: kli...@google.com, llvm-bugs@lists.llvm.org
> cat f.cpp
int i = -1;
int z = 0;
int main() {
return (i << 0) + (i << z);
}
> clang++ -fsanitize=undefined f.cpp
> ./a.out
No error is issued.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30752] unwanted warnings in system headers using #line
https://bugs.llvm.org/show_bug.cgi?id=30752 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Reid Kleckner --- Fixed in r303582. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33132] New: test-suite/ABI-Testsuite/test/mangling/test.cpp depends on dual c++11 ABI
https://bugs.llvm.org/show_bug.cgi?id=33132
Bug ID: 33132
Summary: test-suite/ABI-Testsuite/test/mangling/test.cpp
depends on dual c++11 ABI
Product: Test Suite
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Programs Tests
Assignee: unassignedb...@nondot.org
Reporter: gkistan...@gmail.com
CC: llvm-bugs@lists.llvm.org
test-suite/ABI-Testsuite/test/mangling/test.cpp
depends on dual c++11 ABI, but does not handle the variations gracefully.
In particular, this check fails in case of the new c++11 ABI
// CHECK-DAG: _Z3fooSs
void
foo(std::basic_string, std::allocator >) {}
as the following effectively gets mangled:
void
foo(std::__cxx11::basic_string,
std::allocator >)
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33096] Wrong relocation type in relocatable LTO link
https://bugs.llvm.org/show_bug.cgi?id=33096 Evgeniy Stepanov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Evgeniy Stepanov --- Fixed in r303578 (gold) and r303579 (lld). -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32146] Enable -verify-machineinstrs with EXPENSIVE_CHECKS
https://bugs.llvm.org/show_bug.cgi?id=32146 Bug 32146 depends on bug 33048, which changed state. Bug 33048 Summary: Hexagon check has a bunch of machine verifier errors https://bugs.llvm.org/show_bug.cgi?id=33048 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33048] Hexagon check has a bunch of machine verifier errors
https://bugs.llvm.org/show_bug.cgi?id=33048 Krzysztof Parzyszek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Krzysztof Parzyszek --- Fixed in r303572. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33131] New: lld makes enormous zero filled MIPS binary
https://bugs.llvm.org/show_bug.cgi?id=33131
Bug ID: 33131
Summary: lld makes enormous zero filled MIPS binary
Product: lld
Version: unspecified
Hardware: Other
OS: NetBSD
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: co...@sdf.org
CC: llvm-bugs@lists.llvm.org
using clang 4.0.0 and lld 4.0.0 on NetBSD-7.99.71/amd64.
using very simple code:
int main() { return 0; }
if I change /usr/bin/ld to be lld and running the command:
$ clang --target=mipsel--netbsd7.99 -mips32r2 -integrated-as -nostdlib -o
test test.c
/usr/bin/ld: warning: cannot find entry symbol __start; defaulting to 0x2
if /usr/bin/ld is lld, I get a 129K test file.
xxd shows it is mostly zero filled until 0x2
I made /usr/bin/ld a sufficiently compatible mips binutils linker, and using
the same command it makes a 1.4K binary (but picks a different entry point)
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33127] clang bus error at optimization level 1 or higher
https://bugs.llvm.org/show_bug.cgi?id=33127 Todd C. Miller changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Todd C. Miller --- It looks like this is due to a local change I have in qsort() and not an llvm bug. Apologies for the false alarm. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33130] New: clang-format resets comment indentation before ifdefs
https://bugs.llvm.org/show_bug.cgi?id=33130
Bug ID: 33130
Summary: clang-format resets comment indentation before ifdefs
Product: clang
Version: 4.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: clemens...@gmail.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Hi,
when running clang-format over a large in-house C source base, I noticed that
it resets the indentation of comments before ifdefs to 0, although an empty
line was placed between comment and #ifdef.
(I understand that it resets the indentation to 0 if the comment is directly
before the ifdef, because then, we can assume that the comment belongs to the
ifdef)
But if there is an empty line in between, I think the comment should instead
follow the indentation from the code before the ifdef or (if unsure),
clang-format should just keep it as it was. (?)
Example:
It changes:
void f(void)
{
char c;
/* Comment */
#ifdef FOO
...
Into:
void f(void)
{
char c;
/* Comment */
#ifdef FOO
...
I am using clang-format 4.0.0 but I don't think this ever worked (tried many
versions in the past few years).
Thanks,
Clemens
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33129] New: wrong code at -Os and -O2 on x86_64-linux-gnu (in NewGVN with "-mllvm -enable-newgvn")
https://bugs.llvm.org/show_bug.cgi?id=33129
Bug ID: 33129
Summary: wrong code at -Os and -O2 on x86_64-linux-gnu (in
NewGVN with "-mllvm -enable-newgvn")
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
This appears to be a very recent regression.
$ clang -v
clang version 5.0.0 (trunk 303542)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/clang-trunk/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang -Os small.c; ./a.out; echo $?
0
$ clang -Os -mllvm -enable-newgvn small.c
$ ./a.out; echo $?
1
$
--
int a, b, c;
int fn1 ()
{
unsigned e = c = 0;
for (; c < 1; c++)
for (; e < 1; e++)
{
int f;
if (!a)
return b;
}
return 1;
}
int main ()
{
return fn1 ();
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33128] New: Re-evaluate loop unrolling for size
https://bugs.llvm.org/show_bug.cgi?id=33128
Bug ID: 33128
Summary: Re-evaluate loop unrolling for size
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: dav...@freebsd.org
CC: davi...@google.com, era...@google.com,
fil...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, simon.f.whitta...@gmail.com,
tejohn...@google.com, xinlian...@gmail.com
Currently, LLVM doesn't run `-loop-unroll` *at all* at -Os.
GCC, OTOH, does it, and this allows them to reduce the size of the generated
code, e.g. when unrolling loops with small (constant) trip counts:
https://godbolt.org/g/PpF4DG
extern int f(int);
int tinkywinky(void) {
int x;
for (int i = 0; i < 2; ++i) {
x += f(i);
}
return x;
}
[davide@cupiditate unroll]$ gcc -Os unroll.c -c -o unroll-gcc.o
[davide@cupiditate unroll]$ ../clang -Os unroll.c -c -o unroll-clang.o
[davide@cupiditate unroll]$ size unroll-gcc.o
textdata bss dec hex filename
80 0 0 80 50 unroll-gcc.o
[davide@cupiditate unroll]$ size unroll-clang.o
textdata bss dec hex filename
86 0 0 86 56 unroll-clang.o
We could also consider having this driven by profile informations to unroll
regions that are hot (and never touch regions that are cold). This has to make
conservative decisions as loop unrolling is an optimization that generally
increases the size of the final executable.
CC:ing some GCC/PGO experts for thoughts.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33127] New: clang bus error at optimization level 1 or higher
https://bugs.llvm.org/show_bug.cgi?id=33127 Bug ID: 33127 Summary: clang bus error at optimization level 1 or higher Product: clang Version: 4.0 Hardware: PC OS: OpenBSD Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: todd.mil...@courtesan.com CC: llvm-bugs@lists.llvm.org Created attachment 18488 --> https://bugs.llvm.org/attachment.cgi?id=18488&action=edit qsort_test.c (unprocessed) $ /usr/local/bin/clang -v -O1 -c /usr/src/regress/lib/libc/qsort/qsort_test.c clang version 4.0.0 (tags/RELEASE_400/final) Target: amd64-unknown-openbsd6.1 Thread model: posix InstalledDir: /usr/local/bin "/usr/local/bin/clang-4.0" -cc1 -triple amd64-unknown-openbsd6.1 -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name qsort_test.c -mrelocation-model pic -pic-level 1 -pic-is-pie -mthread-model posix -mdisable-fp-elim -relaxed-aliasing -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v -dwarf-column-info -debugger-tuning=gdb -coverage-notes-file /usr/src/regress/lib/libc/qsort/qsort_test.gcno -resource-dir /usr/local/bin/../lib/clang/4.0.0 -O1 -fdebug-compilation-dir /usr/src/regress/lib/libc/qsort -ferror-limit 19 -fmessage-length 80 -stack-protector 2 -fobjc-runtime=gnustep -fdiagnostics-show-option -o qsort_test.o -x c /usr/src/regress/lib/libc/qsort/qsort_test.c clang -cc1 version 4.0.0 based upon LLVM 4.0.0 default target amd64-unknown-openbsd6.1 #include "..." search starts here: #include <...> search starts here: /usr/local/bin/../lib/clang/4.0.0/include /usr/include End of search list. clang-4.0: error: unable to execute command: Bus error (core dumped) clang-4.0: error: clang frontend command failed due to signal (use -v to see invocation) clang version 4.0.0 (tags/RELEASE_400/final) Target: amd64-unknown-openbsd6.1 Thread model: posix InstalledDir: /usr/local/bin clang-4.0: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-4.0: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-4.0: note: diagnostic msg: /tmp/qsort_test-108960.c clang-4.0: note: diagnostic msg: /tmp/qsort_test-108960.sh clang-4.0: note: diagnostic msg: xerxes [/usr/src/regress/lib/libc/qsort] % -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33126] New: MemorySSA could cache alias query results more aggressively
https://bugs.llvm.org/show_bug.cgi?id=33126 Bug ID: 33126 Summary: MemorySSA could cache alias query results more aggressively Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: dav...@freebsd.org CC: dber...@dberlin.org, george.burgess...@gmail.com, llvm-bugs@lists.llvm.org Dumping this one here, for whomever gets to it first (as I have a terrible memory, and probably will forget in a day or two). Dan run ./opt -memoryssa on clang.bc and statistics return: 1175012 memoryssa - Number of MemorySSA alias queries 360784 memoryssa - Number of MemorySSA duplicate pointer queries Which is a pretty significant amount of duplicate queries. In the conducted experiments, caching everything saves 20% of MemorySSA time, but the amount of memory used could be a concern for large testcases (e.g. LTO). Probably using a smarter cache could lead to substantial benefits without memory usage going crazy. It's unclear what's the best policy, maybe LRU is a good starting point. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33107] Inlined subroutine with empty ranges / duplicate linkable entries
https://bugs.llvm.org/show_bug.cgi?id=33107 Adrian Prantl changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Adrian Prantl --- Should be fixed by r303566. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33125] New: std::function copies movable objects when is SOO is used
https://bugs.llvm.org/show_bug.cgi?id=33125 Bug ID: 33125 Summary: std::function copies movable objects when is SOO is used Product: libc++ Version: 3.7 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: kiber...@yandex-team.ru CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Created attachment 18487 --> https://bugs.llvm.org/attachment.cgi?id=18487&action=edit Test case Hi. Libc++ that comes with Xcode 8.2.1 has small object optimization implemented for std::function. But move constructor of std::function always uses copy constructor of the object. This results in unnecessary copies being made and additional destructor calls. In our use case this even leads to crashes because the object is a handle and we rely that it will be destroyed on specific thread. But that extra copies, created while the std::function is dispatched to the worker thread, result in destructor being deleted at another time and from another thread. It would be good if moving std::function object resulted in moving the underlying functor if it is movable. I've attached a test program, that demonstrates the problem. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32536] Verification failed in HuffEnc
https://bugs.llvm.org/show_bug.cgi?id=32536 Michael Kruse changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Michael Kruse --- Fix in r303561. Thanks to Baranidharan Mohan for the fix. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33124] New: ARCMT does not handle \r\n correctly
https://bugs.llvm.org/show_bug.cgi?id=33124 Bug ID: 33124 Summary: ARCMT does not handle \r\n correctly Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: erik.verbrug...@me.com CC: llvm-bugs@lists.llvm.org When rewriting, the ranges which include the "end of line" (so \n on unix) do not handle windows line endings (\r\n): the size of considered to be 1. So, on Windows, the result file contains sequences of \r\r\n as line-endings. This is not visible when running the test-suite from an svn check-out, because the test files are marked as binary. However, with a git repository on windows, this is quite visible. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33122] New: Merge r302416 into the 4.0 branch
https://bugs.llvm.org/show_bug.cgi?id=33122 Bug ID: 33122 Summary: Merge r302416 into the 4.0 branch Product: libraries Version: 4.0 Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: mar...@martin.st CC: llvm-bugs@lists.llvm.org This fixes PR32825, which is a regression since llvm 3.9. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32825] arm assembler incorrectly re-uses previously allocated literal pool entries
https://bugs.llvm.org/show_bug.cgi?id=32825 James Molloy changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from James Molloy --- Hi, It turns out that this PR was fixed by r302416. I have checked the testcase and it behaves correctly on ToT. I have therefore re-applied the two commits I backed out, and am marking this as FIXED. Cheers, James -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 33121] New: Incorrect formatting of lambdas with option UseTab: ForIndentation
https://bugs.llvm.org/show_bug.cgi?id=33121 Bug ID: 33121 Summary: Incorrect formatting of lambdas with option UseTab: ForIndentation Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: farkas.szil...@gmail.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Created attachment 18485 --> https://bugs.llvm.org/attachment.cgi?id=18485&action=edit Format Options + Actual and Expected output When a lambda is enclosed between parentheses (pretty often), spaces are used in indentation instead of tabs even when using UseTab: ForIndentation option. Indenting with tabs always is not an option for me it makes indentation even worse. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
