[PATCH] D68695: [clang-format] Update noexcept reference qualifiers detection

[Krasimir Georgiev via Phabricator via cfe-commits]

krasimir created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
krasimir added reviewers: AndWass, MyDeveloperDay.

r373165 fixed an issue where a templated noexcept member function with a
reference qualifier would be indented more than expected:

  // Formatting produced with LLVM style with AlwaysBreakTemplateDeclarations: Yes
  
  // before r373165:
  struct f {
    template <class T>
        void bar() && noexcept {}
  };
  
  // after:
  struct f {
    template <class T>
    void bar() && noexcept {}
  };

The way this is done is that in the AnnotatingParser in
`lib/FormatTokenAnnotator.cpp` the determination of the usage of a `&` or `&&`
(the line in determineTokenType

  Current.Type = determineStarAmpUsage(...

is not performed in some cases anymore, combining with a few additional related
checks afterwards. The net effect of these checks results in the `&` or `&&`
token to start being classified as `TT_Unknown` in cases where before `r373165`
it would be classified as `TT_UnaryOperator` or `TT_PointerOrReference` by
`determineStarAmpUsage`.

This inadvertently caused 2 classes of regressions I'm aware of:

- The address-of `&` after a function assignment would be classified as `TT_Unknown`, causing spaces to surround it, disregarding style options:

  // before r373165:
  void (*fun_ptr)(void) = &fun;
  
  // after:
  void (*fun_ptr)(void) = & fun;



- In cases where there is a function declaration list -- looking macro between a template line and the start of the function declaration, an `&` as part of the return type would be classified as `TT_Unknown`, causing spaces to surround it:

  // before r373165:
  template <class T>
  DEPRECATED("lala")
  Type& foo();
  
  // after:
  template <class T>
  DEPRECATED("lala")
  Type & foo();

In these cases the problems are rooted in the skipping of the classification of
a `&` (and similarly `&&`) by determineStarAmpUsage which effects the formatting
decisions later in the pipeline.

I've looked into the goal of r373165 and noticed that replacing `noexcept` with
`const` in the given example produces no extra indentation with the old code:

  // before r373165:
  struct f {
    template <class T>
    int foo() & const {}
  };
  
  struct f {
    template <class T>
        int foo() & noexcept {}
  };

I investigated how clang-format annotated these two examples differently to
determine the places where the processing of both diverges in the pipeline.
There were two places where the processing diverges, causing the extra indent in
the `noexcept` case:

1. The `const` is annotated as a `TT_TrailingAnnotation`, whereas `noexcept` is annotated as `TT_Unknown`. I've updated the `determineTokenType` function to account for this by adding a missing `tok:kw_noexcept` to the clause that marks a token as `TT_TrailingAnnotation`.
2. The `&` in the second example is wrongly identified as `TT_BinaryOperator` in `determineStarAmpUsage`. This is the reason for the extra indentation -- clang-format gets confused and thinks this is an expression. I've updated `determineStarAmpUsage` to check for `tok:kw_noexcept`.

With these two updates in place, the additional parsing introduced by r373165
becomes unnecessary and all added tests pass (with updates, as now clang-format
respects the style configuration for spaces around the `&` in the test
examples).
I've removed these additions and added regression tests for the cases above.


Repository:
  rC Clang

https://reviews.llvm.org/D68695

Files:
  lib/Format/TokenAnnotator.cpp
  unittests/Format/FormatTest.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D68695.224022.patch
Type: text/x-patch
Size: 6479 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20191009/cbe73cd2/attachment.bin>