[all-commits] [llvm/llvm-project] b685e1: [clan-format] detect function definitions more con...

[Owen via All-commits]

  Branch: refs/heads/release/13.x
  Home:   https://github.com/llvm/llvm-project
  Commit: b685e13d1130a969dd58fb917a61eef5a33c0552
      https://github.com/llvm/llvm-project/commit/b685e13d1130a969dd58fb917a61eef5a33c0552
  Author: Krasimir Georgiev <krasimir at google.com>
  Date:   2021-09-09 (Thu, 09 Sep 2021)

  Changed paths:
    M clang/lib/Format/TokenAnnotator.cpp
    M clang/unittests/Format/FormatTest.cpp

  Log Message:
  -----------
  [clan-format] detect function definitions more conservatively

https://reviews.llvm.org/D105964 updated the detection of function
definitions. It had the unfortunate effect to start marking object
definitions with attribute-like macros as function definitions.

This addresses this issue.

Reviewed By: owenpan

Differential Revision: https://reviews.llvm.org/D107269

(cherry picked from commit f6bc614546e169bb1b17a29c422ebace038e6c62)


  Commit: ffd90ed19988658fcf1add9c7b9c19153e19cb74
      https://github.com/llvm/llvm-project/commit/ffd90ed19988658fcf1add9c7b9c19153e19cb74
  Author: Krasimir Georgiev <krasimir at google.com>
  Date:   2021-09-09 (Thu, 09 Sep 2021)

  Changed paths:
    M clang/lib/Format/TokenAnnotator.cpp
    M clang/unittests/Format/FormatTest.cpp

  Log Message:
  -----------
  [clang-format] handle trailing comments in function definition detection

A follow-up to
https://github.com/llvm/llvm-project/commit/f6bc614546e169bb1b17a29c422ebace038e6c62
where we handle the case where the semicolon is followed by a trailing
comment.

Reviewed By: MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D107907

(cherry picked from commit 0fc27ef19670676689d3317948c81eb171bb25f8)


  Commit: 748f09fdd5d61e64e485a7125d56bc217b5ba491
      https://github.com/llvm/llvm-project/commit/748f09fdd5d61e64e485a7125d56bc217b5ba491
  Author: Krasimir Georgiev <krasimir at google.com>
  Date:   2021-09-09 (Thu, 09 Sep 2021)

  Changed paths:
    M clang/lib/Format/UnwrappedLineParser.cpp
    M clang/unittests/Format/FormatTest.cpp

  Log Message:
  -----------
  [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

(cherry picked from commit 45934922fa88b7542c8bcd86889d062fb78efdda)


  Commit: 4ab7fe9228dbc7dc521d9cd4afeff7eac3b43c32
      https://github.com/llvm/llvm-project/commit/4ab7fe9228dbc7dc521d9cd4afeff7eac3b43c32
  Author: Owen <owenca at users.noreply.github.com>
  Date:   2021-09-09 (Thu, 09 Sep 2021)

  Changed paths:
    M clang/lib/Format/UnwrappedLineParser.cpp
    M clang/unittests/Format/FormatTest.cpp

  Log Message:
  -----------
  [clang-format] Distinguish K&R C function definition and attribute

This is a follow-up to https://reviews.llvm.org/D107950 which
missed user-defined types in K&R C.

Differential Revision: https://reviews.llvm.org/D107961

(cherry picked from commit f6928cf45516503deb48f8175a982becc579dc8c)


  Commit: c8d8248488a387d8e948ddfcbef0f1efa8c30f65
      https://github.com/llvm/llvm-project/commit/c8d8248488a387d8e948ddfcbef0f1efa8c30f65
  Author: owenca <owenpiano at gmail.com>
  Date:   2021-09-09 (Thu, 09 Sep 2021)

  Changed paths:
    M clang/lib/Format/UnwrappedLineParser.cpp

  Log Message:
  -----------
  [clang-format] Improve detection of parameter declarations in K&R C

Clean up the detection of parameter declarations in K&R C function
definitions. Also make it more precise by requiring the second
token after the r_paren to be either a star or keyword/identifier.

Differential Revision: https://reviews.llvm.org/D108094

(cherry picked from commmit 643f2be7b6afd91d9f0d6df89cd3391835763112)


Compare: https://github.com/llvm/llvm-project/compare/e3ec9058aae5...c8d8248488a3