| Issue |
107434
|
| Summary |
clang-format can consume an unreasonable amount of memory when ColumnLimit != 0
|
| Labels |
clang-format
|
| Assignees |
|
| Reporter |
nicolas-guichard
|
Using the attached [reproducer.c](https://github.com/user-attachments/files/16897629/reproducer.txt):
```
> time -v clang-format --style='{ColumnLimit: 0}' reproducer.c
User time (seconds): 0.56
Maximum resident set size (kbytes): 265132 (265 MB)
> time -v clang-format --style='{ColumnLimit: 80}' reproducer.c
User time (seconds): 68.73
Maximum resident set size (kbytes): 13737072 (13.7 GB, 51× increase)
```
That reproducer is certainly special, being more than 2 MB on a single line. It is the result of a macro expansion in WebKit's [bmalloc_heap_config.h](https://searchfox.org/wubkat/rev/b36cbce69fddb7da33823f316bd8ead5bebee970/Source/bmalloc/libpas/src/libpas/bmalloc_heap_config.h). We encountered this when trying to expose macro expansions in Searchfox, leading to https://bugzilla.mozilla.org/show_bug.cgi?id=1912078. Our clang plugin uses `clang::format::reformat`.
I think bailing out when a line is too complex to be broken down would be a good first step. I see [OptimizingLineFormatter](https://searchfox.org/llvm/rev/c2b92a4250b3f514685676ba8985ea73450f14d3/clang/lib/Format/UnwrappedLineFormatter.cpp#1245-1246) has that kind of logic already.
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs