Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This patch fixes the regression caused by 2183fe2 while introducing a new regression. But in my opinion the new regression is less of a problem than the old one. Therefore I think it is okay.
Take this piece of code similar to the example in 71814b4.
before
void SomeFunction(int param1, template < #ifdef A #if 0 #endif MyType<Some>> #else Type1, Type2> #endif param2, param3) { f(); }
after
void SomeFunction(int param1, template < #ifdef A #if 0 #endif MyType<Some>> #else Type1, Type2 > #endif param2, param3) { f(); }
clang/lib/Format/UnwrappedLineParser.cpp | ||
---|---|---|
1150 | Can you add a comment here saying this line is a nasty hack which breaks the assumption that PPChainBranchIndex should have as many entries as the number of nestings of preprocessor branches and we should probably come up with a better way? |
It just occurred to me that klimek is the one who added all this stuff. Why didn't you include him as a reviewer?
@djasper and @klimek name is likely all over the code, as they were the "founding fathers of clang-format", hopefully they are off doing something new and exciting, but those of us here on the reviewers list along with @curdeius are really the core clang-format team at this time. Hopefully we are qualified enough. (actually @owenpan is likely the most qualified ;-) )
We do our best to stay true to the original designers goals and be good custodians of clang-format, but my hope is they are watching over us even from afar but we assume they trust us with their baby!
We tend not to ask them to give back more unless they want to.
I added a test (lines 6130-6136) for #elif but not #elifdef and #elifndef because all three are on the same execution path in the parser (lines 1113-1115). Actually, they all call the same function (via parsePPElIf()) that #else does. This is probably why none of them has a separate test in the LayoutStatementsAroundPreprocessorDirectives unit test. So I will do the opposite and remove the test for #elif. :)
Can you add a comment here saying this line is a nasty hack which breaks the assumption that PPChainBranchIndex should have as many entries as the number of nestings of preprocessor branches and we should probably come up with a better way?