2019-10-10 16:27:14 +02:00
|
|
|
//===- FileCheck.cpp - Check that File's Contents match what is expected --===//
|
|
|
|
//
|
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// FileCheck does a line-by line check of a file that validates whether it
|
|
|
|
// contains the expected content. This is useful for regression tests etc.
|
|
|
|
//
|
|
|
|
// This program exits with an exit status of 2 on error, exit status of 0 if
|
|
|
|
// the file matched the expected contents, and exit status of 1 if it did not
|
|
|
|
// contain the expected contents.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/Support/CommandLine.h"
|
|
|
|
#include "llvm/Support/InitLLVM.h"
|
|
|
|
#include "llvm/Support/Process.h"
|
|
|
|
#include "llvm/Support/WithColor.h"
|
|
|
|
#include "llvm/Support/raw_ostream.h"
|
|
|
|
#include "llvm/Support/FileCheck.h"
|
|
|
|
#include <cmath>
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
static cl::extrahelp FileCheckOptsEnv(
|
|
|
|
"\nOptions are parsed from the environment variable FILECHECK_OPTS and\n"
|
|
|
|
"from the command line.\n");
|
|
|
|
|
|
|
|
static cl::opt<std::string>
|
|
|
|
CheckFilename(cl::Positional, cl::desc("<check-file>"), cl::Optional);
|
|
|
|
|
|
|
|
static cl::opt<std::string>
|
|
|
|
InputFilename("input-file", cl::desc("File to check (defaults to stdin)"),
|
|
|
|
cl::init("-"), cl::value_desc("filename"));
|
|
|
|
|
|
|
|
static cl::list<std::string> CheckPrefixes(
|
|
|
|
"check-prefix",
|
|
|
|
cl::desc("Prefix to use from check file (defaults to 'CHECK')"));
|
|
|
|
static cl::alias CheckPrefixesAlias(
|
|
|
|
"check-prefixes", cl::aliasopt(CheckPrefixes), cl::CommaSeparated,
|
|
|
|
cl::NotHidden,
|
|
|
|
cl::desc(
|
|
|
|
"Alias for -check-prefix permitting multiple comma separated values"));
|
|
|
|
|
[FileCheck] Support comment directives
Sometimes you want to disable a FileCheck directive without removing
it entirely, or you want to write comments that mention a directive by
name. The `COM:` directive makes it easy to do this. For example,
you might have:
```
; X32: pinsrd_1:
; X32: pinsrd $1, 4(%esp), %xmm0
; COM: FIXME: X64 isn't working correctly yet for this part of codegen, but
; COM: X64 will have something similar to X32:
; COM:
; COM: X64: pinsrd_1:
; COM: X64: pinsrd $1, %edi, %xmm0
```
Without this patch, you need to use some combination of rewording and
directive syntax mangling to prevent FileCheck from recognizing the
commented occurrences of `X32:` and `X64:` above as directives.
Moreover, FileCheck diagnostics have been proposed that might complain
about the occurrences of `X64` that don't have the trailing `:`
because they look like directive typos:
<http://lists.llvm.org/pipermail/llvm-dev/2020-April/140610.html>
I think dodging all these problems can prove tedious for test authors,
and directive syntax mangling already makes the purpose of existing
test code unclear. `COM:` can avoid all these problems.
This patch also updates the small set of existing tests that define
`COM` as a check prefix:
- clang/test/CodeGen/default-address-space.c
- clang/test/CodeGenOpenCL/addr-space-struct-arg.cl
- clang/test/Driver/hip-device-libs.hip
- llvm/test/Assembler/drop-debug-info-nonzero-alloca.ll
I think lit should support `COM:` as well. Perhaps `clang -verify`
should too.
Reviewed By: jhenderson, thopre
Differential Revision: https://reviews.llvm.org/D79276
2020-05-05 00:05:55 +02:00
|
|
|
static cl::list<std::string> CommentPrefixes(
|
|
|
|
"comment-prefixes", cl::CommaSeparated, cl::Hidden,
|
|
|
|
cl::desc("Comma-separated list of comment prefixes to use from check file\n"
|
|
|
|
"(defaults to 'COM,RUN'). Please avoid using this feature in\n"
|
|
|
|
"LLVM's LIT-based test suites, which should be easier to\n"
|
|
|
|
"maintain if they all follow a consistent comment style. This\n"
|
|
|
|
"feature is meant for non-LIT test suites using FileCheck."));
|
|
|
|
|
2019-10-10 16:27:14 +02:00
|
|
|
static cl::opt<bool> NoCanonicalizeWhiteSpace(
|
|
|
|
"strict-whitespace",
|
|
|
|
cl::desc("Do not treat all horizontal whitespace as equivalent"));
|
|
|
|
|
2019-10-11 13:59:14 +02:00
|
|
|
static cl::opt<bool> IgnoreCase(
|
|
|
|
"ignore-case",
|
|
|
|
cl::desc("Use case-insensitive matching"));
|
|
|
|
|
2019-10-10 16:27:14 +02:00
|
|
|
static cl::list<std::string> ImplicitCheckNot(
|
|
|
|
"implicit-check-not",
|
|
|
|
cl::desc("Add an implicit negative check with this pattern to every\n"
|
|
|
|
"positive check. This can be used to ensure that no instances of\n"
|
|
|
|
"this pattern occur which are not matched by a positive pattern"),
|
|
|
|
cl::value_desc("pattern"));
|
|
|
|
|
|
|
|
static cl::list<std::string>
|
|
|
|
GlobalDefines("D", cl::AlwaysPrefix,
|
|
|
|
cl::desc("Define a variable to be used in capture patterns."),
|
|
|
|
cl::value_desc("VAR=VALUE"));
|
|
|
|
|
|
|
|
static cl::opt<bool> AllowEmptyInput(
|
|
|
|
"allow-empty", cl::init(false),
|
|
|
|
cl::desc("Allow the input file to be empty. This is useful when making\n"
|
|
|
|
"checks that some error message does not occur, for example."));
|
|
|
|
|
|
|
|
static cl::opt<bool> MatchFullLines(
|
|
|
|
"match-full-lines", cl::init(false),
|
|
|
|
cl::desc("Require all positive matches to cover an entire input line.\n"
|
|
|
|
"Allows leading and trailing whitespace if --strict-whitespace\n"
|
|
|
|
"is not also passed."));
|
|
|
|
|
|
|
|
static cl::opt<bool> EnableVarScope(
|
|
|
|
"enable-var-scope", cl::init(false),
|
|
|
|
cl::desc("Enables scope for regex variables. Variables with names that\n"
|
|
|
|
"do not start with '$' will be reset at the beginning of\n"
|
|
|
|
"each CHECK-LABEL block."));
|
|
|
|
|
|
|
|
static cl::opt<bool> AllowDeprecatedDagOverlap(
|
|
|
|
"allow-deprecated-dag-overlap", cl::init(false),
|
|
|
|
cl::desc("Enable overlapping among matches in a group of consecutive\n"
|
|
|
|
"CHECK-DAG directives. This option is deprecated and is only\n"
|
|
|
|
"provided for convenience as old tests are migrated to the new\n"
|
|
|
|
"non-overlapping CHECK-DAG implementation.\n"));
|
|
|
|
|
|
|
|
static cl::opt<bool> Verbose(
|
2020-06-30 00:35:22 +02:00
|
|
|
"v", cl::init(false), cl::ZeroOrMore,
|
2019-10-10 16:27:14 +02:00
|
|
|
cl::desc("Print directive pattern matches, or add them to the input dump\n"
|
|
|
|
"if enabled.\n"));
|
|
|
|
|
|
|
|
static cl::opt<bool> VerboseVerbose(
|
2020-06-30 00:35:22 +02:00
|
|
|
"vv", cl::init(false), cl::ZeroOrMore,
|
2019-10-10 16:27:14 +02:00
|
|
|
cl::desc("Print information helpful in diagnosing internal FileCheck\n"
|
|
|
|
"issues, or add it to the input dump if enabled. Implies\n"
|
|
|
|
"-v.\n"));
|
|
|
|
|
[FileCheck] Given multiple -dump-input, prefer most verbose
Problem: `FILECHECK_OPTS` was implemented so that a test runner, such
as a bot, can specify FileCheck debugging options, such as
`-dump-input=fail`. However, some existing test suites have FileCheck
calls that already specify `-dump-input=fail` or `-dump-input=always`.
Without this patch, such tests fail under such a test runner because
FileCheck doesn't accept multiple occurrences of `-dump-input`.
Solution: This patch permits multiple occurrences of `-dump-input` by
assigning precedence to its values in the following descending order:
`help`, `always`, `fail`, and `never`. That is, any occurrence of
`help` always obtains help, and otherwise the behavior is similar to
`-v` vs. `-vv` in that the option specifying the greatest verbosity
has precedence.
Rationale: My justification for the new behavior is as follows. I
have not experienced use cases where, either as a test runner or as a
test author, I want to **limit** the permitted debugging verbosity
(except as a test author in FileCheck's or lit's test suites where the
FileCheck debugging output itself is under test, but the solution
there is `env FILECHECK_OPTS=`, and I imagine we should use the same
solution anywhere else this need might occur). Of course, as either a
test runner or test author, it is useful to **increase** debugging
verbosity.
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D70784
2019-12-03 16:13:00 +01:00
|
|
|
// The order of DumpInputValue members affects their precedence, as documented
|
|
|
|
// for -dump-input below.
|
2019-10-10 16:27:14 +02:00
|
|
|
enum DumpInputValue {
|
|
|
|
DumpInputNever,
|
|
|
|
DumpInputFail,
|
[FileCheck] Given multiple -dump-input, prefer most verbose
Problem: `FILECHECK_OPTS` was implemented so that a test runner, such
as a bot, can specify FileCheck debugging options, such as
`-dump-input=fail`. However, some existing test suites have FileCheck
calls that already specify `-dump-input=fail` or `-dump-input=always`.
Without this patch, such tests fail under such a test runner because
FileCheck doesn't accept multiple occurrences of `-dump-input`.
Solution: This patch permits multiple occurrences of `-dump-input` by
assigning precedence to its values in the following descending order:
`help`, `always`, `fail`, and `never`. That is, any occurrence of
`help` always obtains help, and otherwise the behavior is similar to
`-v` vs. `-vv` in that the option specifying the greatest verbosity
has precedence.
Rationale: My justification for the new behavior is as follows. I
have not experienced use cases where, either as a test runner or as a
test author, I want to **limit** the permitted debugging verbosity
(except as a test author in FileCheck's or lit's test suites where the
FileCheck debugging output itself is under test, but the solution
there is `env FILECHECK_OPTS=`, and I imagine we should use the same
solution anywhere else this need might occur). Of course, as either a
test runner or test author, it is useful to **increase** debugging
verbosity.
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D70784
2019-12-03 16:13:00 +01:00
|
|
|
DumpInputAlways,
|
|
|
|
DumpInputHelp
|
2019-10-10 16:27:14 +02:00
|
|
|
};
|
|
|
|
|
[FileCheck] Given multiple -dump-input, prefer most verbose
Problem: `FILECHECK_OPTS` was implemented so that a test runner, such
as a bot, can specify FileCheck debugging options, such as
`-dump-input=fail`. However, some existing test suites have FileCheck
calls that already specify `-dump-input=fail` or `-dump-input=always`.
Without this patch, such tests fail under such a test runner because
FileCheck doesn't accept multiple occurrences of `-dump-input`.
Solution: This patch permits multiple occurrences of `-dump-input` by
assigning precedence to its values in the following descending order:
`help`, `always`, `fail`, and `never`. That is, any occurrence of
`help` always obtains help, and otherwise the behavior is similar to
`-v` vs. `-vv` in that the option specifying the greatest verbosity
has precedence.
Rationale: My justification for the new behavior is as follows. I
have not experienced use cases where, either as a test runner or as a
test author, I want to **limit** the permitted debugging verbosity
(except as a test author in FileCheck's or lit's test suites where the
FileCheck debugging output itself is under test, but the solution
there is `env FILECHECK_OPTS=`, and I imagine we should use the same
solution anywhere else this need might occur). Of course, as either a
test runner or test author, it is useful to **increase** debugging
verbosity.
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D70784
2019-12-03 16:13:00 +01:00
|
|
|
static cl::list<DumpInputValue> DumpInputs(
|
|
|
|
"dump-input",
|
2019-10-10 16:27:14 +02:00
|
|
|
cl::desc("Dump input to stderr, adding annotations representing\n"
|
[FileCheck] Given multiple -dump-input, prefer most verbose
Problem: `FILECHECK_OPTS` was implemented so that a test runner, such
as a bot, can specify FileCheck debugging options, such as
`-dump-input=fail`. However, some existing test suites have FileCheck
calls that already specify `-dump-input=fail` or `-dump-input=always`.
Without this patch, such tests fail under such a test runner because
FileCheck doesn't accept multiple occurrences of `-dump-input`.
Solution: This patch permits multiple occurrences of `-dump-input` by
assigning precedence to its values in the following descending order:
`help`, `always`, `fail`, and `never`. That is, any occurrence of
`help` always obtains help, and otherwise the behavior is similar to
`-v` vs. `-vv` in that the option specifying the greatest verbosity
has precedence.
Rationale: My justification for the new behavior is as follows. I
have not experienced use cases where, either as a test runner or as a
test author, I want to **limit** the permitted debugging verbosity
(except as a test author in FileCheck's or lit's test suites where the
FileCheck debugging output itself is under test, but the solution
there is `env FILECHECK_OPTS=`, and I imagine we should use the same
solution anywhere else this need might occur). Of course, as either a
test runner or test author, it is useful to **increase** debugging
verbosity.
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D70784
2019-12-03 16:13:00 +01:00
|
|
|
"currently enabled diagnostics. When there are multiple\n"
|
|
|
|
"occurrences of this option, the <value> that appears earliest\n"
|
2020-07-09 23:31:31 +02:00
|
|
|
"in the list below has precedence. The default is 'fail'.\n"),
|
2019-10-10 16:27:14 +02:00
|
|
|
cl::value_desc("mode"),
|
2020-07-09 23:31:31 +02:00
|
|
|
cl::values(clEnumValN(DumpInputHelp, "help", "Explain input dump and quit"),
|
[FileCheck] Given multiple -dump-input, prefer most verbose
Problem: `FILECHECK_OPTS` was implemented so that a test runner, such
as a bot, can specify FileCheck debugging options, such as
`-dump-input=fail`. However, some existing test suites have FileCheck
calls that already specify `-dump-input=fail` or `-dump-input=always`.
Without this patch, such tests fail under such a test runner because
FileCheck doesn't accept multiple occurrences of `-dump-input`.
Solution: This patch permits multiple occurrences of `-dump-input` by
assigning precedence to its values in the following descending order:
`help`, `always`, `fail`, and `never`. That is, any occurrence of
`help` always obtains help, and otherwise the behavior is similar to
`-v` vs. `-vv` in that the option specifying the greatest verbosity
has precedence.
Rationale: My justification for the new behavior is as follows. I
have not experienced use cases where, either as a test runner or as a
test author, I want to **limit** the permitted debugging verbosity
(except as a test author in FileCheck's or lit's test suites where the
FileCheck debugging output itself is under test, but the solution
there is `env FILECHECK_OPTS=`, and I imagine we should use the same
solution anywhere else this need might occur). Of course, as either a
test runner or test author, it is useful to **increase** debugging
verbosity.
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D70784
2019-12-03 16:13:00 +01:00
|
|
|
clEnumValN(DumpInputAlways, "always", "Always dump input"),
|
2019-10-10 16:27:14 +02:00
|
|
|
clEnumValN(DumpInputFail, "fail", "Dump input on failure"),
|
[FileCheck] Given multiple -dump-input, prefer most verbose
Problem: `FILECHECK_OPTS` was implemented so that a test runner, such
as a bot, can specify FileCheck debugging options, such as
`-dump-input=fail`. However, some existing test suites have FileCheck
calls that already specify `-dump-input=fail` or `-dump-input=always`.
Without this patch, such tests fail under such a test runner because
FileCheck doesn't accept multiple occurrences of `-dump-input`.
Solution: This patch permits multiple occurrences of `-dump-input` by
assigning precedence to its values in the following descending order:
`help`, `always`, `fail`, and `never`. That is, any occurrence of
`help` always obtains help, and otherwise the behavior is similar to
`-v` vs. `-vv` in that the option specifying the greatest verbosity
has precedence.
Rationale: My justification for the new behavior is as follows. I
have not experienced use cases where, either as a test runner or as a
test author, I want to **limit** the permitted debugging verbosity
(except as a test author in FileCheck's or lit's test suites where the
FileCheck debugging output itself is under test, but the solution
there is `env FILECHECK_OPTS=`, and I imagine we should use the same
solution anywhere else this need might occur). Of course, as either a
test runner or test author, it is useful to **increase** debugging
verbosity.
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D70784
2019-12-03 16:13:00 +01:00
|
|
|
clEnumValN(DumpInputNever, "never", "Never dump input")));
|
2019-10-10 16:27:14 +02:00
|
|
|
|
|
|
|
typedef cl::list<std::string>::const_iterator prefix_iterator;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static void DumpCommandLine(int argc, char **argv) {
|
|
|
|
errs() << "FileCheck command line: ";
|
|
|
|
for (int I = 0; I < argc; I++)
|
|
|
|
errs() << " " << argv[I];
|
|
|
|
errs() << "\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
struct MarkerStyle {
|
|
|
|
/// The starting char (before tildes) for marking the line.
|
|
|
|
char Lead;
|
|
|
|
/// What color to use for this annotation.
|
|
|
|
raw_ostream::Colors Color;
|
|
|
|
/// A note to follow the marker, or empty string if none.
|
|
|
|
std::string Note;
|
|
|
|
MarkerStyle() {}
|
|
|
|
MarkerStyle(char Lead, raw_ostream::Colors Color,
|
|
|
|
const std::string &Note = "")
|
|
|
|
: Lead(Lead), Color(Color), Note(Note) {}
|
|
|
|
};
|
|
|
|
|
|
|
|
static MarkerStyle GetMarker(FileCheckDiag::MatchType MatchTy) {
|
|
|
|
switch (MatchTy) {
|
|
|
|
case FileCheckDiag::MatchFoundAndExpected:
|
|
|
|
return MarkerStyle('^', raw_ostream::GREEN);
|
|
|
|
case FileCheckDiag::MatchFoundButExcluded:
|
|
|
|
return MarkerStyle('!', raw_ostream::RED, "error: no match expected");
|
|
|
|
case FileCheckDiag::MatchFoundButWrongLine:
|
|
|
|
return MarkerStyle('!', raw_ostream::RED, "error: match on wrong line");
|
|
|
|
case FileCheckDiag::MatchFoundButDiscarded:
|
|
|
|
return MarkerStyle('!', raw_ostream::CYAN,
|
|
|
|
"discard: overlaps earlier match");
|
|
|
|
case FileCheckDiag::MatchNoneAndExcluded:
|
|
|
|
return MarkerStyle('X', raw_ostream::GREEN);
|
|
|
|
case FileCheckDiag::MatchNoneButExpected:
|
|
|
|
return MarkerStyle('X', raw_ostream::RED, "error: no match found");
|
|
|
|
case FileCheckDiag::MatchFuzzy:
|
|
|
|
return MarkerStyle('?', raw_ostream::MAGENTA, "possible intended match");
|
|
|
|
}
|
|
|
|
llvm_unreachable_internal("unexpected match type");
|
|
|
|
}
|
|
|
|
|
|
|
|
static void DumpInputAnnotationHelp(raw_ostream &OS) {
|
|
|
|
OS << "The following description was requested by -dump-input=help to\n"
|
2020-07-09 23:31:31 +02:00
|
|
|
<< "explain the input dump printed by FileCheck.\n"
|
|
|
|
<< "\n"
|
|
|
|
<< "Related command-line options:\n"
|
|
|
|
<< " - -dump-input=<value> enables or disables the input dump\n"
|
|
|
|
<< " - -v and -vv add more annotations\n"
|
|
|
|
<< " - -color forces colors to be enabled both in the dump and below\n"
|
|
|
|
<< " - -help documents the above options in more detail\n"
|
|
|
|
<< "\n"
|
|
|
|
<< "Input dump annotation format:\n";
|
2019-10-10 16:27:14 +02:00
|
|
|
|
|
|
|
// Labels for input lines.
|
|
|
|
OS << " - ";
|
|
|
|
WithColor(OS, raw_ostream::SAVEDCOLOR, true) << "L:";
|
|
|
|
OS << " labels line number L of the input file\n";
|
|
|
|
|
|
|
|
// Labels for annotation lines.
|
|
|
|
OS << " - ";
|
|
|
|
WithColor(OS, raw_ostream::SAVEDCOLOR, true) << "T:L";
|
2020-04-16 20:53:44 +02:00
|
|
|
OS << " labels the only match result for either (1) a pattern of type T"
|
|
|
|
<< " from\n"
|
|
|
|
<< " line L of the check file if L is an integer or (2) the"
|
|
|
|
<< " I-th implicit\n"
|
|
|
|
<< " pattern if L is \"imp\" followed by an integer "
|
|
|
|
<< "I (index origin one)\n";
|
2019-10-10 16:27:14 +02:00
|
|
|
OS << " - ";
|
|
|
|
WithColor(OS, raw_ostream::SAVEDCOLOR, true) << "T:L'N";
|
2020-04-16 20:53:44 +02:00
|
|
|
OS << " labels the Nth match result for such a pattern\n";
|
2019-10-10 16:27:14 +02:00
|
|
|
|
|
|
|
// Markers on annotation lines.
|
|
|
|
OS << " - ";
|
|
|
|
WithColor(OS, raw_ostream::SAVEDCOLOR, true) << "^~~";
|
|
|
|
OS << " marks good match (reported if -v)\n"
|
|
|
|
<< " - ";
|
|
|
|
WithColor(OS, raw_ostream::SAVEDCOLOR, true) << "!~~";
|
|
|
|
OS << " marks bad match, such as:\n"
|
|
|
|
<< " - CHECK-NEXT on same line as previous match (error)\n"
|
|
|
|
<< " - CHECK-NOT found (error)\n"
|
|
|
|
<< " - CHECK-DAG overlapping match (discarded, reported if "
|
|
|
|
<< "-vv)\n"
|
|
|
|
<< " - ";
|
|
|
|
WithColor(OS, raw_ostream::SAVEDCOLOR, true) << "X~~";
|
|
|
|
OS << " marks search range when no match is found, such as:\n"
|
|
|
|
<< " - CHECK-NEXT not found (error)\n"
|
|
|
|
<< " - CHECK-NOT not found (success, reported if -vv)\n"
|
|
|
|
<< " - CHECK-DAG not found after discarded matches (error)\n"
|
|
|
|
<< " - ";
|
|
|
|
WithColor(OS, raw_ostream::SAVEDCOLOR, true) << "?";
|
|
|
|
OS << " marks fuzzy match when no match is found\n";
|
|
|
|
|
|
|
|
// Colors.
|
|
|
|
OS << " - colors ";
|
|
|
|
WithColor(OS, raw_ostream::GREEN, true) << "success";
|
|
|
|
OS << ", ";
|
|
|
|
WithColor(OS, raw_ostream::RED, true) << "error";
|
|
|
|
OS << ", ";
|
|
|
|
WithColor(OS, raw_ostream::MAGENTA, true) << "fuzzy match";
|
|
|
|
OS << ", ";
|
|
|
|
WithColor(OS, raw_ostream::CYAN, true, false) << "discarded match";
|
|
|
|
OS << ", ";
|
|
|
|
WithColor(OS, raw_ostream::CYAN, true, true) << "unmatched input";
|
2020-07-09 23:31:31 +02:00
|
|
|
OS << "\n";
|
2019-10-10 16:27:14 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/// An annotation for a single input line.
|
|
|
|
struct InputAnnotation {
|
[FileCheck] Fix --dump-input annotation sort per input line
Without this patch, `--dump-input` annotations on a single input line
are sorted by the associated directive's check-file line. That seemed
fine because that's often identical to the order in which FileCheck
looks for matches for those directives.
The first problem is that an `--implicit-check-not` pattern has no
check-file line. The logical equivalent is sorting in command-line
order, but that's not implemented.
The second problem is that, unlike a directive, an
`--implicit-check-not` pattern applies at many points, between many
different pairs of directives. However, sorting in command-line order
gathers all its associated diagnostics together at one point in an
input line's list of annotations.
In general, it seems to be easier to understand FileCheck's logic when
annotations on a single input line are sorted in the order FileCheck
produced the associated diagnostics, so this patch makes that change.
As documented in the patch, the annotation sort order is also
especially relevant to `CHECK-LABEL`, `CHECK-NOT`, and `CHECK-DAG`, so
this patch updates or extends tests to check the sort makes sense for
them. (However, the sort for `CHECK-DAG` annotations should not
actually be altered by this patch.)
Reviewed By: thopre
Differential Revision: https://reviews.llvm.org/D77607
2020-04-16 20:53:56 +02:00
|
|
|
/// The index of the match result across all checks
|
|
|
|
unsigned DiagIndex;
|
2019-10-10 16:27:14 +02:00
|
|
|
/// The label for this annotation.
|
|
|
|
std::string Label;
|
|
|
|
/// What input line (one-origin indexing) this annotation marks. This might
|
|
|
|
/// be different from the starting line of the original diagnostic if this is
|
|
|
|
/// a non-initial fragment of a diagnostic that has been broken across
|
|
|
|
/// multiple lines.
|
|
|
|
unsigned InputLine;
|
[FileCheck] Fix --dump-input annotation sort per input line
Without this patch, `--dump-input` annotations on a single input line
are sorted by the associated directive's check-file line. That seemed
fine because that's often identical to the order in which FileCheck
looks for matches for those directives.
The first problem is that an `--implicit-check-not` pattern has no
check-file line. The logical equivalent is sorting in command-line
order, but that's not implemented.
The second problem is that, unlike a directive, an
`--implicit-check-not` pattern applies at many points, between many
different pairs of directives. However, sorting in command-line order
gathers all its associated diagnostics together at one point in an
input line's list of annotations.
In general, it seems to be easier to understand FileCheck's logic when
annotations on a single input line are sorted in the order FileCheck
produced the associated diagnostics, so this patch makes that change.
As documented in the patch, the annotation sort order is also
especially relevant to `CHECK-LABEL`, `CHECK-NOT`, and `CHECK-DAG`, so
this patch updates or extends tests to check the sort makes sense for
them. (However, the sort for `CHECK-DAG` annotations should not
actually be altered by this patch.)
Reviewed By: thopre
Differential Revision: https://reviews.llvm.org/D77607
2020-04-16 20:53:56 +02:00
|
|
|
/// The column range (one-origin indexing, open end) in which to mark the
|
2019-10-10 16:27:14 +02:00
|
|
|
/// input line. If InputEndCol is UINT_MAX, treat it as the last column
|
|
|
|
/// before the newline.
|
|
|
|
unsigned InputStartCol, InputEndCol;
|
|
|
|
/// The marker to use.
|
|
|
|
MarkerStyle Marker;
|
|
|
|
/// Whether this annotation represents a good match for an expected pattern.
|
|
|
|
bool FoundAndExpectedMatch;
|
|
|
|
};
|
|
|
|
|
|
|
|
/// Get an abbreviation for the check type.
|
|
|
|
std::string GetCheckTypeAbbreviation(Check::FileCheckType Ty) {
|
|
|
|
switch (Ty) {
|
|
|
|
case Check::CheckPlain:
|
|
|
|
if (Ty.getCount() > 1)
|
|
|
|
return "count";
|
|
|
|
return "check";
|
|
|
|
case Check::CheckNext:
|
|
|
|
return "next";
|
|
|
|
case Check::CheckSame:
|
|
|
|
return "same";
|
|
|
|
case Check::CheckNot:
|
|
|
|
return "not";
|
|
|
|
case Check::CheckDAG:
|
|
|
|
return "dag";
|
|
|
|
case Check::CheckLabel:
|
|
|
|
return "label";
|
|
|
|
case Check::CheckEmpty:
|
|
|
|
return "empty";
|
[FileCheck] Support comment directives
Sometimes you want to disable a FileCheck directive without removing
it entirely, or you want to write comments that mention a directive by
name. The `COM:` directive makes it easy to do this. For example,
you might have:
```
; X32: pinsrd_1:
; X32: pinsrd $1, 4(%esp), %xmm0
; COM: FIXME: X64 isn't working correctly yet for this part of codegen, but
; COM: X64 will have something similar to X32:
; COM:
; COM: X64: pinsrd_1:
; COM: X64: pinsrd $1, %edi, %xmm0
```
Without this patch, you need to use some combination of rewording and
directive syntax mangling to prevent FileCheck from recognizing the
commented occurrences of `X32:` and `X64:` above as directives.
Moreover, FileCheck diagnostics have been proposed that might complain
about the occurrences of `X64` that don't have the trailing `:`
because they look like directive typos:
<http://lists.llvm.org/pipermail/llvm-dev/2020-April/140610.html>
I think dodging all these problems can prove tedious for test authors,
and directive syntax mangling already makes the purpose of existing
test code unclear. `COM:` can avoid all these problems.
This patch also updates the small set of existing tests that define
`COM` as a check prefix:
- clang/test/CodeGen/default-address-space.c
- clang/test/CodeGenOpenCL/addr-space-struct-arg.cl
- clang/test/Driver/hip-device-libs.hip
- llvm/test/Assembler/drop-debug-info-nonzero-alloca.ll
I think lit should support `COM:` as well. Perhaps `clang -verify`
should too.
Reviewed By: jhenderson, thopre
Differential Revision: https://reviews.llvm.org/D79276
2020-05-05 00:05:55 +02:00
|
|
|
case Check::CheckComment:
|
|
|
|
return "com";
|
2019-10-10 16:27:14 +02:00
|
|
|
case Check::CheckEOF:
|
|
|
|
return "eof";
|
|
|
|
case Check::CheckBadNot:
|
|
|
|
return "bad-not";
|
|
|
|
case Check::CheckBadCount:
|
|
|
|
return "bad-count";
|
|
|
|
case Check::CheckNone:
|
|
|
|
llvm_unreachable("invalid FileCheckType");
|
|
|
|
}
|
|
|
|
llvm_unreachable("unknown FileCheckType");
|
|
|
|
}
|
|
|
|
|
2020-04-16 20:53:44 +02:00
|
|
|
static void
|
|
|
|
BuildInputAnnotations(const SourceMgr &SM, unsigned CheckFileBufferID,
|
|
|
|
const std::pair<unsigned, unsigned> &ImpPatBufferIDRange,
|
|
|
|
const std::vector<FileCheckDiag> &Diags,
|
|
|
|
std::vector<InputAnnotation> &Annotations,
|
|
|
|
unsigned &LabelWidth) {
|
[FileCheck] Fix --dump-input annotation sort per input line
Without this patch, `--dump-input` annotations on a single input line
are sorted by the associated directive's check-file line. That seemed
fine because that's often identical to the order in which FileCheck
looks for matches for those directives.
The first problem is that an `--implicit-check-not` pattern has no
check-file line. The logical equivalent is sorting in command-line
order, but that's not implemented.
The second problem is that, unlike a directive, an
`--implicit-check-not` pattern applies at many points, between many
different pairs of directives. However, sorting in command-line order
gathers all its associated diagnostics together at one point in an
input line's list of annotations.
In general, it seems to be easier to understand FileCheck's logic when
annotations on a single input line are sorted in the order FileCheck
produced the associated diagnostics, so this patch makes that change.
As documented in the patch, the annotation sort order is also
especially relevant to `CHECK-LABEL`, `CHECK-NOT`, and `CHECK-DAG`, so
this patch updates or extends tests to check the sort makes sense for
them. (However, the sort for `CHECK-DAG` annotations should not
actually be altered by this patch.)
Reviewed By: thopre
Differential Revision: https://reviews.llvm.org/D77607
2020-04-16 20:53:56 +02:00
|
|
|
// How many diagnostics have we seen so far?
|
|
|
|
unsigned DiagCount = 0;
|
2019-10-10 16:27:14 +02:00
|
|
|
// How many diagnostics has the current check seen so far?
|
|
|
|
unsigned CheckDiagCount = 0;
|
|
|
|
// What's the widest label?
|
|
|
|
LabelWidth = 0;
|
|
|
|
for (auto DiagItr = Diags.begin(), DiagEnd = Diags.end(); DiagItr != DiagEnd;
|
|
|
|
++DiagItr) {
|
|
|
|
InputAnnotation A;
|
[FileCheck] Fix --dump-input annotation sort per input line
Without this patch, `--dump-input` annotations on a single input line
are sorted by the associated directive's check-file line. That seemed
fine because that's often identical to the order in which FileCheck
looks for matches for those directives.
The first problem is that an `--implicit-check-not` pattern has no
check-file line. The logical equivalent is sorting in command-line
order, but that's not implemented.
The second problem is that, unlike a directive, an
`--implicit-check-not` pattern applies at many points, between many
different pairs of directives. However, sorting in command-line order
gathers all its associated diagnostics together at one point in an
input line's list of annotations.
In general, it seems to be easier to understand FileCheck's logic when
annotations on a single input line are sorted in the order FileCheck
produced the associated diagnostics, so this patch makes that change.
As documented in the patch, the annotation sort order is also
especially relevant to `CHECK-LABEL`, `CHECK-NOT`, and `CHECK-DAG`, so
this patch updates or extends tests to check the sort makes sense for
them. (However, the sort for `CHECK-DAG` annotations should not
actually be altered by this patch.)
Reviewed By: thopre
Differential Revision: https://reviews.llvm.org/D77607
2020-04-16 20:53:56 +02:00
|
|
|
A.DiagIndex = DiagCount++;
|
2019-10-10 16:27:14 +02:00
|
|
|
|
|
|
|
// Build label, which uniquely identifies this check result.
|
2020-04-16 20:53:44 +02:00
|
|
|
unsigned CheckBufferID = SM.FindBufferContainingLoc(DiagItr->CheckLoc);
|
|
|
|
auto CheckLineAndCol =
|
|
|
|
SM.getLineAndColumn(DiagItr->CheckLoc, CheckBufferID);
|
2019-10-10 16:27:14 +02:00
|
|
|
llvm::raw_string_ostream Label(A.Label);
|
2020-04-16 20:53:44 +02:00
|
|
|
Label << GetCheckTypeAbbreviation(DiagItr->CheckTy) << ":";
|
|
|
|
if (CheckBufferID == CheckFileBufferID)
|
|
|
|
Label << CheckLineAndCol.first;
|
|
|
|
else if (ImpPatBufferIDRange.first <= CheckBufferID &&
|
|
|
|
CheckBufferID < ImpPatBufferIDRange.second)
|
|
|
|
Label << "imp" << (CheckBufferID - ImpPatBufferIDRange.first + 1);
|
|
|
|
else
|
|
|
|
llvm_unreachable("expected diagnostic's check location to be either in "
|
|
|
|
"the check file or for an implicit pattern");
|
[FileCheck] Fix --dump-input annotation sort per input line
Without this patch, `--dump-input` annotations on a single input line
are sorted by the associated directive's check-file line. That seemed
fine because that's often identical to the order in which FileCheck
looks for matches for those directives.
The first problem is that an `--implicit-check-not` pattern has no
check-file line. The logical equivalent is sorting in command-line
order, but that's not implemented.
The second problem is that, unlike a directive, an
`--implicit-check-not` pattern applies at many points, between many
different pairs of directives. However, sorting in command-line order
gathers all its associated diagnostics together at one point in an
input line's list of annotations.
In general, it seems to be easier to understand FileCheck's logic when
annotations on a single input line are sorted in the order FileCheck
produced the associated diagnostics, so this patch makes that change.
As documented in the patch, the annotation sort order is also
especially relevant to `CHECK-LABEL`, `CHECK-NOT`, and `CHECK-DAG`, so
this patch updates or extends tests to check the sort makes sense for
them. (However, the sort for `CHECK-DAG` annotations should not
actually be altered by this patch.)
Reviewed By: thopre
Differential Revision: https://reviews.llvm.org/D77607
2020-04-16 20:53:56 +02:00
|
|
|
unsigned CheckDiagIndex = UINT_MAX;
|
2019-10-10 16:27:14 +02:00
|
|
|
auto DiagNext = std::next(DiagItr);
|
|
|
|
if (DiagNext != DiagEnd && DiagItr->CheckTy == DiagNext->CheckTy &&
|
2020-04-16 20:53:44 +02:00
|
|
|
DiagItr->CheckLoc == DiagNext->CheckLoc)
|
[FileCheck] Fix --dump-input annotation sort per input line
Without this patch, `--dump-input` annotations on a single input line
are sorted by the associated directive's check-file line. That seemed
fine because that's often identical to the order in which FileCheck
looks for matches for those directives.
The first problem is that an `--implicit-check-not` pattern has no
check-file line. The logical equivalent is sorting in command-line
order, but that's not implemented.
The second problem is that, unlike a directive, an
`--implicit-check-not` pattern applies at many points, between many
different pairs of directives. However, sorting in command-line order
gathers all its associated diagnostics together at one point in an
input line's list of annotations.
In general, it seems to be easier to understand FileCheck's logic when
annotations on a single input line are sorted in the order FileCheck
produced the associated diagnostics, so this patch makes that change.
As documented in the patch, the annotation sort order is also
especially relevant to `CHECK-LABEL`, `CHECK-NOT`, and `CHECK-DAG`, so
this patch updates or extends tests to check the sort makes sense for
them. (However, the sort for `CHECK-DAG` annotations should not
actually be altered by this patch.)
Reviewed By: thopre
Differential Revision: https://reviews.llvm.org/D77607
2020-04-16 20:53:56 +02:00
|
|
|
CheckDiagIndex = CheckDiagCount++;
|
2019-10-10 16:27:14 +02:00
|
|
|
else if (CheckDiagCount) {
|
[FileCheck] Fix --dump-input annotation sort per input line
Without this patch, `--dump-input` annotations on a single input line
are sorted by the associated directive's check-file line. That seemed
fine because that's often identical to the order in which FileCheck
looks for matches for those directives.
The first problem is that an `--implicit-check-not` pattern has no
check-file line. The logical equivalent is sorting in command-line
order, but that's not implemented.
The second problem is that, unlike a directive, an
`--implicit-check-not` pattern applies at many points, between many
different pairs of directives. However, sorting in command-line order
gathers all its associated diagnostics together at one point in an
input line's list of annotations.
In general, it seems to be easier to understand FileCheck's logic when
annotations on a single input line are sorted in the order FileCheck
produced the associated diagnostics, so this patch makes that change.
As documented in the patch, the annotation sort order is also
especially relevant to `CHECK-LABEL`, `CHECK-NOT`, and `CHECK-DAG`, so
this patch updates or extends tests to check the sort makes sense for
them. (However, the sort for `CHECK-DAG` annotations should not
actually be altered by this patch.)
Reviewed By: thopre
Differential Revision: https://reviews.llvm.org/D77607
2020-04-16 20:53:56 +02:00
|
|
|
CheckDiagIndex = CheckDiagCount;
|
2019-10-10 16:27:14 +02:00
|
|
|
CheckDiagCount = 0;
|
|
|
|
}
|
[FileCheck] Fix --dump-input annotation sort per input line
Without this patch, `--dump-input` annotations on a single input line
are sorted by the associated directive's check-file line. That seemed
fine because that's often identical to the order in which FileCheck
looks for matches for those directives.
The first problem is that an `--implicit-check-not` pattern has no
check-file line. The logical equivalent is sorting in command-line
order, but that's not implemented.
The second problem is that, unlike a directive, an
`--implicit-check-not` pattern applies at many points, between many
different pairs of directives. However, sorting in command-line order
gathers all its associated diagnostics together at one point in an
input line's list of annotations.
In general, it seems to be easier to understand FileCheck's logic when
annotations on a single input line are sorted in the order FileCheck
produced the associated diagnostics, so this patch makes that change.
As documented in the patch, the annotation sort order is also
especially relevant to `CHECK-LABEL`, `CHECK-NOT`, and `CHECK-DAG`, so
this patch updates or extends tests to check the sort makes sense for
them. (However, the sort for `CHECK-DAG` annotations should not
actually be altered by this patch.)
Reviewed By: thopre
Differential Revision: https://reviews.llvm.org/D77607
2020-04-16 20:53:56 +02:00
|
|
|
if (CheckDiagIndex != UINT_MAX)
|
|
|
|
Label << "'" << CheckDiagIndex;
|
2019-10-10 16:27:14 +02:00
|
|
|
Label.flush();
|
|
|
|
LabelWidth = std::max((std::string::size_type)LabelWidth, A.Label.size());
|
|
|
|
|
|
|
|
A.Marker = GetMarker(DiagItr->MatchTy);
|
|
|
|
A.FoundAndExpectedMatch =
|
|
|
|
DiagItr->MatchTy == FileCheckDiag::MatchFoundAndExpected;
|
|
|
|
|
|
|
|
// Compute the mark location, and break annotation into multiple
|
|
|
|
// annotations if it spans multiple lines.
|
|
|
|
A.InputLine = DiagItr->InputStartLine;
|
|
|
|
A.InputStartCol = DiagItr->InputStartCol;
|
|
|
|
if (DiagItr->InputStartLine == DiagItr->InputEndLine) {
|
|
|
|
// Sometimes ranges are empty in order to indicate a specific point, but
|
|
|
|
// that would mean nothing would be marked, so adjust the range to
|
|
|
|
// include the following character.
|
|
|
|
A.InputEndCol =
|
|
|
|
std::max(DiagItr->InputStartCol + 1, DiagItr->InputEndCol);
|
|
|
|
Annotations.push_back(A);
|
|
|
|
} else {
|
|
|
|
assert(DiagItr->InputStartLine < DiagItr->InputEndLine &&
|
|
|
|
"expected input range not to be inverted");
|
|
|
|
A.InputEndCol = UINT_MAX;
|
|
|
|
Annotations.push_back(A);
|
|
|
|
for (unsigned L = DiagItr->InputStartLine + 1, E = DiagItr->InputEndLine;
|
|
|
|
L <= E; ++L) {
|
|
|
|
// If a range ends before the first column on a line, then it has no
|
|
|
|
// characters on that line, so there's nothing to render.
|
|
|
|
if (DiagItr->InputEndCol == 1 && L == E)
|
|
|
|
break;
|
|
|
|
InputAnnotation B;
|
[FileCheck] Fix --dump-input annotation sort per input line
Without this patch, `--dump-input` annotations on a single input line
are sorted by the associated directive's check-file line. That seemed
fine because that's often identical to the order in which FileCheck
looks for matches for those directives.
The first problem is that an `--implicit-check-not` pattern has no
check-file line. The logical equivalent is sorting in command-line
order, but that's not implemented.
The second problem is that, unlike a directive, an
`--implicit-check-not` pattern applies at many points, between many
different pairs of directives. However, sorting in command-line order
gathers all its associated diagnostics together at one point in an
input line's list of annotations.
In general, it seems to be easier to understand FileCheck's logic when
annotations on a single input line are sorted in the order FileCheck
produced the associated diagnostics, so this patch makes that change.
As documented in the patch, the annotation sort order is also
especially relevant to `CHECK-LABEL`, `CHECK-NOT`, and `CHECK-DAG`, so
this patch updates or extends tests to check the sort makes sense for
them. (However, the sort for `CHECK-DAG` annotations should not
actually be altered by this patch.)
Reviewed By: thopre
Differential Revision: https://reviews.llvm.org/D77607
2020-04-16 20:53:56 +02:00
|
|
|
B.DiagIndex = A.DiagIndex;
|
2019-10-10 16:27:14 +02:00
|
|
|
B.Label = A.Label;
|
|
|
|
B.InputLine = L;
|
|
|
|
B.Marker = A.Marker;
|
|
|
|
B.Marker.Lead = '~';
|
|
|
|
B.Marker.Note = "";
|
|
|
|
B.InputStartCol = 1;
|
|
|
|
if (L != E)
|
|
|
|
B.InputEndCol = UINT_MAX;
|
|
|
|
else
|
|
|
|
B.InputEndCol = DiagItr->InputEndCol;
|
|
|
|
B.FoundAndExpectedMatch = A.FoundAndExpectedMatch;
|
|
|
|
Annotations.push_back(B);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void DumpAnnotatedInput(raw_ostream &OS, const FileCheckRequest &Req,
|
|
|
|
StringRef InputFileText,
|
|
|
|
std::vector<InputAnnotation> &Annotations,
|
|
|
|
unsigned LabelWidth) {
|
|
|
|
OS << "Full input was:\n<<<<<<\n";
|
|
|
|
|
|
|
|
// Sort annotations.
|
|
|
|
std::sort(Annotations.begin(), Annotations.end(),
|
|
|
|
[](const InputAnnotation &A, const InputAnnotation &B) {
|
[FileCheck] Fix --dump-input annotation sort per input line
Without this patch, `--dump-input` annotations on a single input line
are sorted by the associated directive's check-file line. That seemed
fine because that's often identical to the order in which FileCheck
looks for matches for those directives.
The first problem is that an `--implicit-check-not` pattern has no
check-file line. The logical equivalent is sorting in command-line
order, but that's not implemented.
The second problem is that, unlike a directive, an
`--implicit-check-not` pattern applies at many points, between many
different pairs of directives. However, sorting in command-line order
gathers all its associated diagnostics together at one point in an
input line's list of annotations.
In general, it seems to be easier to understand FileCheck's logic when
annotations on a single input line are sorted in the order FileCheck
produced the associated diagnostics, so this patch makes that change.
As documented in the patch, the annotation sort order is also
especially relevant to `CHECK-LABEL`, `CHECK-NOT`, and `CHECK-DAG`, so
this patch updates or extends tests to check the sort makes sense for
them. (However, the sort for `CHECK-DAG` annotations should not
actually be altered by this patch.)
Reviewed By: thopre
Differential Revision: https://reviews.llvm.org/D77607
2020-04-16 20:53:56 +02:00
|
|
|
// 1. Sort annotations in the order of the input lines.
|
|
|
|
//
|
|
|
|
// This makes it easier to find relevant annotations while
|
|
|
|
// iterating input lines in the implementation below. FileCheck
|
|
|
|
// does not always produce diagnostics in the order of input
|
|
|
|
// lines due to, for example, CHECK-DAG and CHECK-NOT.
|
2019-10-10 16:27:14 +02:00
|
|
|
if (A.InputLine != B.InputLine)
|
|
|
|
return A.InputLine < B.InputLine;
|
[FileCheck] Fix --dump-input annotation sort per input line
Without this patch, `--dump-input` annotations on a single input line
are sorted by the associated directive's check-file line. That seemed
fine because that's often identical to the order in which FileCheck
looks for matches for those directives.
The first problem is that an `--implicit-check-not` pattern has no
check-file line. The logical equivalent is sorting in command-line
order, but that's not implemented.
The second problem is that, unlike a directive, an
`--implicit-check-not` pattern applies at many points, between many
different pairs of directives. However, sorting in command-line order
gathers all its associated diagnostics together at one point in an
input line's list of annotations.
In general, it seems to be easier to understand FileCheck's logic when
annotations on a single input line are sorted in the order FileCheck
produced the associated diagnostics, so this patch makes that change.
As documented in the patch, the annotation sort order is also
especially relevant to `CHECK-LABEL`, `CHECK-NOT`, and `CHECK-DAG`, so
this patch updates or extends tests to check the sort makes sense for
them. (However, the sort for `CHECK-DAG` annotations should not
actually be altered by this patch.)
Reviewed By: thopre
Differential Revision: https://reviews.llvm.org/D77607
2020-04-16 20:53:56 +02:00
|
|
|
// 2. Sort annotations in the temporal order FileCheck produced
|
|
|
|
// their associated diagnostics.
|
|
|
|
//
|
|
|
|
// This sort offers several benefits:
|
|
|
|
//
|
|
|
|
// A. On a single input line, the order of annotations reflects
|
|
|
|
// the FileCheck logic for processing directives/patterns.
|
|
|
|
// This can be helpful in understanding cases in which the
|
|
|
|
// order of the associated directives/patterns in the check
|
|
|
|
// file or on the command line either (i) does not match the
|
|
|
|
// temporal order in which FileCheck looks for matches for the
|
|
|
|
// directives/patterns (due to, for example, CHECK-LABEL,
|
|
|
|
// CHECK-NOT, or `--implicit-check-not`) or (ii) does match
|
|
|
|
// that order but does not match the order of those
|
|
|
|
// diagnostics along an input line (due to, for example,
|
|
|
|
// CHECK-DAG).
|
|
|
|
//
|
|
|
|
// On the other hand, because our presentation format presents
|
|
|
|
// input lines in order, there's no clear way to offer the
|
|
|
|
// same benefit across input lines. For consistency, it might
|
|
|
|
// then seem worthwhile to have annotations on a single line
|
|
|
|
// also sorted in input order (that is, by input column).
|
|
|
|
// However, in practice, this appears to be more confusing
|
|
|
|
// than helpful. Perhaps it's intuitive to expect annotations
|
|
|
|
// to be listed in the temporal order in which they were
|
|
|
|
// produced except in cases the presentation format obviously
|
|
|
|
// and inherently cannot support it (that is, across input
|
|
|
|
// lines).
|
|
|
|
//
|
|
|
|
// B. When diagnostics' annotations are split among multiple
|
|
|
|
// input lines, the user must track them from one input line
|
|
|
|
// to the next. One property of the sort chosen here is that
|
|
|
|
// it facilitates the user in this regard by ensuring the
|
|
|
|
// following: when comparing any two input lines, a
|
|
|
|
// diagnostic's annotations are sorted in the same position
|
|
|
|
// relative to all other diagnostics' annotations.
|
|
|
|
return A.DiagIndex < B.DiagIndex;
|
2019-10-10 16:27:14 +02:00
|
|
|
});
|
|
|
|
|
|
|
|
// Compute the width of the label column.
|
|
|
|
const unsigned char *InputFilePtr = InputFileText.bytes_begin(),
|
|
|
|
*InputFileEnd = InputFileText.bytes_end();
|
|
|
|
unsigned LineCount = InputFileText.count('\n');
|
|
|
|
if (InputFileEnd[-1] != '\n')
|
|
|
|
++LineCount;
|
|
|
|
unsigned LineNoWidth = std::log10(LineCount) + 1;
|
|
|
|
// +3 below adds spaces (1) to the left of the (right-aligned) line numbers
|
|
|
|
// on input lines and (2) to the right of the (left-aligned) labels on
|
|
|
|
// annotation lines so that input lines and annotation lines are more
|
|
|
|
// visually distinct. For example, the spaces on the annotation lines ensure
|
|
|
|
// that input line numbers and check directive line numbers never align
|
|
|
|
// horizontally. Those line numbers might not even be for the same file.
|
|
|
|
// One space would be enough to achieve that, but more makes it even easier
|
|
|
|
// to see.
|
|
|
|
LabelWidth = std::max(LabelWidth, LineNoWidth) + 3;
|
|
|
|
|
|
|
|
// Print annotated input lines.
|
|
|
|
auto AnnotationItr = Annotations.begin(), AnnotationEnd = Annotations.end();
|
|
|
|
for (unsigned Line = 1;
|
|
|
|
InputFilePtr != InputFileEnd || AnnotationItr != AnnotationEnd;
|
|
|
|
++Line) {
|
|
|
|
const unsigned char *InputFileLine = InputFilePtr;
|
|
|
|
|
|
|
|
// Print right-aligned line number.
|
|
|
|
WithColor(OS, raw_ostream::BLACK, true)
|
|
|
|
<< format_decimal(Line, LabelWidth) << ": ";
|
|
|
|
|
|
|
|
// For the case where -v and colors are enabled, find the annotations for
|
|
|
|
// good matches for expected patterns in order to highlight everything
|
|
|
|
// else in the line. There are no such annotations if -v is disabled.
|
|
|
|
std::vector<InputAnnotation> FoundAndExpectedMatches;
|
|
|
|
if (Req.Verbose && WithColor(OS).colorsEnabled()) {
|
|
|
|
for (auto I = AnnotationItr; I != AnnotationEnd && I->InputLine == Line;
|
|
|
|
++I) {
|
|
|
|
if (I->FoundAndExpectedMatch)
|
|
|
|
FoundAndExpectedMatches.push_back(*I);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Print numbered line with highlighting where there are no matches for
|
|
|
|
// expected patterns.
|
|
|
|
bool Newline = false;
|
|
|
|
{
|
|
|
|
WithColor COS(OS);
|
|
|
|
bool InMatch = false;
|
|
|
|
if (Req.Verbose)
|
|
|
|
COS.changeColor(raw_ostream::CYAN, true, true);
|
|
|
|
for (unsigned Col = 1; InputFilePtr != InputFileEnd && !Newline; ++Col) {
|
|
|
|
bool WasInMatch = InMatch;
|
|
|
|
InMatch = false;
|
|
|
|
for (auto M : FoundAndExpectedMatches) {
|
|
|
|
if (M.InputStartCol <= Col && Col < M.InputEndCol) {
|
|
|
|
InMatch = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!WasInMatch && InMatch)
|
|
|
|
COS.resetColor();
|
|
|
|
else if (WasInMatch && !InMatch)
|
|
|
|
COS.changeColor(raw_ostream::CYAN, true, true);
|
|
|
|
if (*InputFilePtr == '\n')
|
|
|
|
Newline = true;
|
|
|
|
else
|
|
|
|
COS << *InputFilePtr;
|
|
|
|
++InputFilePtr;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
OS << '\n';
|
|
|
|
unsigned InputLineWidth = InputFilePtr - InputFileLine - Newline;
|
|
|
|
|
|
|
|
// Print any annotations.
|
|
|
|
while (AnnotationItr != AnnotationEnd &&
|
|
|
|
AnnotationItr->InputLine == Line) {
|
|
|
|
WithColor COS(OS, AnnotationItr->Marker.Color, true);
|
|
|
|
// The two spaces below are where the ": " appears on input lines.
|
|
|
|
COS << left_justify(AnnotationItr->Label, LabelWidth) << " ";
|
|
|
|
unsigned Col;
|
|
|
|
for (Col = 1; Col < AnnotationItr->InputStartCol; ++Col)
|
|
|
|
COS << ' ';
|
|
|
|
COS << AnnotationItr->Marker.Lead;
|
|
|
|
// If InputEndCol=UINT_MAX, stop at InputLineWidth.
|
|
|
|
for (++Col; Col < AnnotationItr->InputEndCol && Col <= InputLineWidth;
|
|
|
|
++Col)
|
|
|
|
COS << '~';
|
|
|
|
const std::string &Note = AnnotationItr->Marker.Note;
|
|
|
|
if (!Note.empty()) {
|
|
|
|
// Put the note at the end of the input line. If we were to instead
|
|
|
|
// put the note right after the marker, subsequent annotations for the
|
|
|
|
// same input line might appear to mark this note instead of the input
|
|
|
|
// line.
|
|
|
|
for (; Col <= InputLineWidth; ++Col)
|
|
|
|
COS << ' ';
|
|
|
|
COS << ' ' << Note;
|
|
|
|
}
|
|
|
|
COS << '\n';
|
|
|
|
++AnnotationItr;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
OS << ">>>>>>\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
int main(int argc, char **argv) {
|
|
|
|
// Enable use of ANSI color codes because FileCheck is using them to
|
|
|
|
// highlight text.
|
|
|
|
llvm::sys::Process::UseANSIEscapeCodes(true);
|
|
|
|
|
|
|
|
InitLLVM X(argc, argv);
|
|
|
|
cl::ParseCommandLineOptions(argc, argv, /*Overview*/ "", /*Errs*/ nullptr,
|
|
|
|
"FILECHECK_OPTS");
|
[FileCheck] Given multiple -dump-input, prefer most verbose
Problem: `FILECHECK_OPTS` was implemented so that a test runner, such
as a bot, can specify FileCheck debugging options, such as
`-dump-input=fail`. However, some existing test suites have FileCheck
calls that already specify `-dump-input=fail` or `-dump-input=always`.
Without this patch, such tests fail under such a test runner because
FileCheck doesn't accept multiple occurrences of `-dump-input`.
Solution: This patch permits multiple occurrences of `-dump-input` by
assigning precedence to its values in the following descending order:
`help`, `always`, `fail`, and `never`. That is, any occurrence of
`help` always obtains help, and otherwise the behavior is similar to
`-v` vs. `-vv` in that the option specifying the greatest verbosity
has precedence.
Rationale: My justification for the new behavior is as follows. I
have not experienced use cases where, either as a test runner or as a
test author, I want to **limit** the permitted debugging verbosity
(except as a test author in FileCheck's or lit's test suites where the
FileCheck debugging output itself is under test, but the solution
there is `env FILECHECK_OPTS=`, and I imagine we should use the same
solution anywhere else this need might occur). Of course, as either a
test runner or test author, it is useful to **increase** debugging
verbosity.
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D70784
2019-12-03 16:13:00 +01:00
|
|
|
DumpInputValue DumpInput =
|
|
|
|
DumpInputs.empty()
|
2020-06-25 18:33:20 +02:00
|
|
|
? DumpInputFail
|
[FileCheck] Given multiple -dump-input, prefer most verbose
Problem: `FILECHECK_OPTS` was implemented so that a test runner, such
as a bot, can specify FileCheck debugging options, such as
`-dump-input=fail`. However, some existing test suites have FileCheck
calls that already specify `-dump-input=fail` or `-dump-input=always`.
Without this patch, such tests fail under such a test runner because
FileCheck doesn't accept multiple occurrences of `-dump-input`.
Solution: This patch permits multiple occurrences of `-dump-input` by
assigning precedence to its values in the following descending order:
`help`, `always`, `fail`, and `never`. That is, any occurrence of
`help` always obtains help, and otherwise the behavior is similar to
`-v` vs. `-vv` in that the option specifying the greatest verbosity
has precedence.
Rationale: My justification for the new behavior is as follows. I
have not experienced use cases where, either as a test runner or as a
test author, I want to **limit** the permitted debugging verbosity
(except as a test author in FileCheck's or lit's test suites where the
FileCheck debugging output itself is under test, but the solution
there is `env FILECHECK_OPTS=`, and I imagine we should use the same
solution anywhere else this need might occur). Of course, as either a
test runner or test author, it is useful to **increase** debugging
verbosity.
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D70784
2019-12-03 16:13:00 +01:00
|
|
|
: *std::max_element(DumpInputs.begin(), DumpInputs.end());
|
2019-10-10 16:27:14 +02:00
|
|
|
if (DumpInput == DumpInputHelp) {
|
|
|
|
DumpInputAnnotationHelp(outs());
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (CheckFilename.empty()) {
|
|
|
|
errs() << "<check-file> not specified\n";
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
FileCheckRequest Req;
|
2020-04-15 14:30:21 +02:00
|
|
|
for (StringRef Prefix : CheckPrefixes)
|
2019-10-10 16:27:14 +02:00
|
|
|
Req.CheckPrefixes.push_back(Prefix);
|
|
|
|
|
[FileCheck] Support comment directives
Sometimes you want to disable a FileCheck directive without removing
it entirely, or you want to write comments that mention a directive by
name. The `COM:` directive makes it easy to do this. For example,
you might have:
```
; X32: pinsrd_1:
; X32: pinsrd $1, 4(%esp), %xmm0
; COM: FIXME: X64 isn't working correctly yet for this part of codegen, but
; COM: X64 will have something similar to X32:
; COM:
; COM: X64: pinsrd_1:
; COM: X64: pinsrd $1, %edi, %xmm0
```
Without this patch, you need to use some combination of rewording and
directive syntax mangling to prevent FileCheck from recognizing the
commented occurrences of `X32:` and `X64:` above as directives.
Moreover, FileCheck diagnostics have been proposed that might complain
about the occurrences of `X64` that don't have the trailing `:`
because they look like directive typos:
<http://lists.llvm.org/pipermail/llvm-dev/2020-April/140610.html>
I think dodging all these problems can prove tedious for test authors,
and directive syntax mangling already makes the purpose of existing
test code unclear. `COM:` can avoid all these problems.
This patch also updates the small set of existing tests that define
`COM` as a check prefix:
- clang/test/CodeGen/default-address-space.c
- clang/test/CodeGenOpenCL/addr-space-struct-arg.cl
- clang/test/Driver/hip-device-libs.hip
- llvm/test/Assembler/drop-debug-info-nonzero-alloca.ll
I think lit should support `COM:` as well. Perhaps `clang -verify`
should too.
Reviewed By: jhenderson, thopre
Differential Revision: https://reviews.llvm.org/D79276
2020-05-05 00:05:55 +02:00
|
|
|
for (StringRef Prefix : CommentPrefixes)
|
|
|
|
Req.CommentPrefixes.push_back(Prefix);
|
|
|
|
|
2020-04-15 14:30:21 +02:00
|
|
|
for (StringRef CheckNot : ImplicitCheckNot)
|
2019-10-10 16:27:14 +02:00
|
|
|
Req.ImplicitCheckNot.push_back(CheckNot);
|
|
|
|
|
|
|
|
bool GlobalDefineError = false;
|
2020-04-15 14:30:21 +02:00
|
|
|
for (StringRef G : GlobalDefines) {
|
2019-10-10 16:27:14 +02:00
|
|
|
size_t EqIdx = G.find('=');
|
|
|
|
if (EqIdx == std::string::npos) {
|
|
|
|
errs() << "Missing equal sign in command-line definition '-D" << G
|
|
|
|
<< "'\n";
|
|
|
|
GlobalDefineError = true;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (EqIdx == 0) {
|
|
|
|
errs() << "Missing variable name in command-line definition '-D" << G
|
|
|
|
<< "'\n";
|
|
|
|
GlobalDefineError = true;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
Req.GlobalDefines.push_back(G);
|
|
|
|
}
|
|
|
|
if (GlobalDefineError)
|
|
|
|
return 2;
|
|
|
|
|
|
|
|
Req.AllowEmptyInput = AllowEmptyInput;
|
|
|
|
Req.EnableVarScope = EnableVarScope;
|
|
|
|
Req.AllowDeprecatedDagOverlap = AllowDeprecatedDagOverlap;
|
|
|
|
Req.Verbose = Verbose;
|
|
|
|
Req.VerboseVerbose = VerboseVerbose;
|
|
|
|
Req.NoCanonicalizeWhiteSpace = NoCanonicalizeWhiteSpace;
|
|
|
|
Req.MatchFullLines = MatchFullLines;
|
2019-10-11 13:59:14 +02:00
|
|
|
Req.IgnoreCase = IgnoreCase;
|
2019-10-10 16:27:14 +02:00
|
|
|
|
|
|
|
if (VerboseVerbose)
|
|
|
|
Req.Verbose = true;
|
|
|
|
|
|
|
|
FileCheck FC(Req);
|
2020-05-11 15:57:37 +02:00
|
|
|
if (!FC.ValidateCheckPrefixes())
|
2019-10-10 16:27:14 +02:00
|
|
|
return 2;
|
|
|
|
|
|
|
|
Regex PrefixRE = FC.buildCheckPrefixRegex();
|
|
|
|
std::string REError;
|
|
|
|
if (!PrefixRE.isValid(REError)) {
|
|
|
|
errs() << "Unable to combine check-prefix strings into a prefix regular "
|
|
|
|
"expression! This is likely a bug in FileCheck's verification of "
|
|
|
|
"the check-prefix strings. Regular expression parsing failed "
|
|
|
|
"with the following error: "
|
|
|
|
<< REError << "\n";
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
SourceMgr SM;
|
|
|
|
|
|
|
|
// Read the expected strings from the check file.
|
|
|
|
ErrorOr<std::unique_ptr<MemoryBuffer>> CheckFileOrErr =
|
|
|
|
MemoryBuffer::getFileOrSTDIN(CheckFilename);
|
|
|
|
if (std::error_code EC = CheckFileOrErr.getError()) {
|
|
|
|
errs() << "Could not open check file '" << CheckFilename
|
|
|
|
<< "': " << EC.message() << '\n';
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
MemoryBuffer &CheckFile = *CheckFileOrErr.get();
|
|
|
|
|
|
|
|
SmallString<4096> CheckFileBuffer;
|
|
|
|
StringRef CheckFileText = FC.CanonicalizeFile(CheckFile, CheckFileBuffer);
|
|
|
|
|
2020-04-16 20:53:44 +02:00
|
|
|
unsigned CheckFileBufferID =
|
|
|
|
SM.AddNewSourceBuffer(MemoryBuffer::getMemBuffer(
|
|
|
|
CheckFileText, CheckFile.getBufferIdentifier()),
|
|
|
|
SMLoc());
|
2019-10-10 16:27:14 +02:00
|
|
|
|
2020-04-16 20:53:44 +02:00
|
|
|
std::pair<unsigned, unsigned> ImpPatBufferIDRange;
|
|
|
|
if (FC.readCheckFile(SM, CheckFileText, PrefixRE, &ImpPatBufferIDRange))
|
2019-10-10 16:27:14 +02:00
|
|
|
return 2;
|
|
|
|
|
|
|
|
// Open the file to check and add it to SourceMgr.
|
|
|
|
ErrorOr<std::unique_ptr<MemoryBuffer>> InputFileOrErr =
|
|
|
|
MemoryBuffer::getFileOrSTDIN(InputFilename);
|
2020-02-03 16:13:31 +01:00
|
|
|
if (InputFilename == "-")
|
|
|
|
InputFilename = "<stdin>"; // Overwrite for improved diagnostic messages
|
2019-10-10 16:27:14 +02:00
|
|
|
if (std::error_code EC = InputFileOrErr.getError()) {
|
|
|
|
errs() << "Could not open input file '" << InputFilename
|
|
|
|
<< "': " << EC.message() << '\n';
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
MemoryBuffer &InputFile = *InputFileOrErr.get();
|
|
|
|
|
|
|
|
if (InputFile.getBufferSize() == 0 && !AllowEmptyInput) {
|
|
|
|
errs() << "FileCheck error: '" << InputFilename << "' is empty.\n";
|
|
|
|
DumpCommandLine(argc, argv);
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
SmallString<4096> InputFileBuffer;
|
|
|
|
StringRef InputFileText = FC.CanonicalizeFile(InputFile, InputFileBuffer);
|
|
|
|
|
|
|
|
SM.AddNewSourceBuffer(MemoryBuffer::getMemBuffer(
|
|
|
|
InputFileText, InputFile.getBufferIdentifier()),
|
|
|
|
SMLoc());
|
|
|
|
|
|
|
|
std::vector<FileCheckDiag> Diags;
|
|
|
|
int ExitCode = FC.checkInput(SM, InputFileText,
|
|
|
|
DumpInput == DumpInputNever ? nullptr : &Diags)
|
|
|
|
? EXIT_SUCCESS
|
|
|
|
: 1;
|
|
|
|
if (DumpInput == DumpInputAlways ||
|
|
|
|
(ExitCode == 1 && DumpInput == DumpInputFail)) {
|
|
|
|
errs() << "\n"
|
2020-07-09 23:31:31 +02:00
|
|
|
<< "Input file: " << InputFilename << "\n"
|
2019-10-10 16:27:14 +02:00
|
|
|
<< "Check file: " << CheckFilename << "\n"
|
|
|
|
<< "\n"
|
2020-07-09 23:31:31 +02:00
|
|
|
<< "-dump-input=help explains the following input dump.\n"
|
2019-10-10 16:27:14 +02:00
|
|
|
<< "\n";
|
|
|
|
std::vector<InputAnnotation> Annotations;
|
|
|
|
unsigned LabelWidth;
|
2020-04-16 20:53:44 +02:00
|
|
|
BuildInputAnnotations(SM, CheckFileBufferID, ImpPatBufferIDRange, Diags,
|
|
|
|
Annotations, LabelWidth);
|
2019-10-10 16:27:14 +02:00
|
|
|
DumpAnnotatedInput(errs(), Req, InputFileText, Annotations, LabelWidth);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ExitCode;
|
|
|
|
}
|