aboutsummaryrefslogtreecommitdiff
path: root/flang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorKrasimir Georgiev <krasimir@google.com>2021-08-12 10:26:56 +0200
committerKrasimir Georgiev <krasimir@google.com>2021-08-12 10:29:06 +0200
commit45934922fa88b7542c8bcd86889d062fb78efdda (patch)
treecf089deb92fa63031f5ce4e5f1b3f7008feaf93d /flang/lib/Frontend/CompilerInvocation.cpp
parent6c1468854d70091ec9b53f97ff33e4a09d95443a (diff)
downloadllvm-45934922fa88b7542c8bcd86889d062fb78efdda.zip
llvm-45934922fa88b7542c8bcd86889d062fb78efdda.tar.gz
llvm-45934922fa88b7542c8bcd86889d062fb78efdda.tar.bz2
[clang-format] improve distinction of K&R function definitions vs attributes
After https://github.com/llvm/llvm-project/commit/9da70ab3d43c79116f80fc06aa7cf517374ce42c we saw a few regressions around trailing attribute definitions and in typedefs (examples in the added test cases). There's some tension distinguishing K&R definitions from attributes at the parser level, where we have to decide if we need to put the type of the K&R definition on a new unwrapped line before we have access to the rest of the line, so we're scanning backwards and looking for a pattern like f(a, b). But this type of pattern could also be an attribute macro, or the whole declaration could be a typedef itself. I updated the code to check for a typedef at the beginning of the line and to not consider raw identifiers as possible first K&R declaration (but treated as an attribute macro instead). This is not 100% correct heuristic, but I think it should be reasonably good in practice, where we'll: * likely be in some very C-ish code when using K&R style (e.g., stuff that uses `struct name a;` instead of `name a;` * likely be in some very C++-ish code when using attributes * unlikely mix up the two in the same declaration. Ideally, we should only decide to add the unwrapped line before the K&R declaration after we've scanned the rest of the line an noticed the variable declarations and the semicolon, but the way the parser is organized I don't see a good way to do this in the current parser, which only has good context for the previously visited tokens. I also tried not emitting an unwrapped line there and trying to resolve the situation later in the token annotator and the continuation indenter, and that approach seems promising, but I couldn't make it to work without messing up a bunch of other cases in unit tests. Reviewed By: MyDeveloperDay Differential Revision: https://reviews.llvm.org/D107950
Diffstat (limited to 'flang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions