[all-commits] [llvm/llvm-project] 09c357: [FileCheck] Do not skip end of line in diagnostics

[RoboTux via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 09c35739035e23279e9369b8bf048288781a3d60
      https://github.com/llvm/llvm-project/commit/09c35739035e23279e9369b8bf048288781a3d60
  Author: Thomas Preud'homme <thomasp at graphcore.ai>
  Date:   2021-03-03 (Wed, 03 Mar 2021)

  Changed paths:
    M llvm/lib/FileCheck/FileCheck.cpp
    M llvm/test/FileCheck/dump-input-annotations.txt
    M llvm/test/FileCheck/dump-input-context.txt
    M llvm/test/FileCheck/dump-input-enable.txt
    M llvm/test/FileCheck/dump-input-filter.txt
    M llvm/test/FileCheck/numeric-expression.txt
    M llvm/test/FileCheck/verbose.txt
    M llvm/utils/FileCheck/FileCheck.cpp

  Log Message:
  -----------
  [FileCheck] Do not skip end of line in diagnostics

When commit da108b4ed4e6e7267701e76d5fd3b87609c9ab77 introduced
the CHECK-NEXT directive, it added logic to skip to the next line when
printing a diagnostic if the current matching position is at the end of
a line. This was fine while FileCheck did not support regular expression
but since it does now it can be confusing when the pattern to match
starts with the expectation of a newline (e.g. CHECK-NEXT: {{\n}}foo).
It is also inconsistent with the column information in the diagnostic
which does point to the end of line.

This commit removes this logic altogether, such that failure to match
diagnostic for such cases would show the end of line and be consistent
with the column information. The commit also adapts all existing
testcases accordingly.

Note to reviewers: An alternative approach would be to restrict the code
to only skip to the next line if the first character of the pattern is
known not to match a whitespace-like character. This would respect the
original intent but keep the inconsistency in terms of column info and
requires more code. I've only chosen this current approach by laziness
and would be happy to restrict the logic instead.

Reviewed By: jdenny, jhenderson

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