class VerifyDiagnosticConsumer

Declaration

class VerifyDiagnosticConsumer : public DiagnosticConsumer,
                                 public CommentHandler { /* full declaration omitted */ };

Description

VerifyDiagnosticConsumer - Create a diagnostic client which will use markers in the input source to check that all the emitted diagnostics match those expected. INVOKING THE DIAGNOSTIC CHECKER: VerifyDiagnosticConsumer is typically invoked via the "-verify" option to "clang -cc1". "-verify" is equivalent to "-verify=expected", so all diagnostics are typically specified with the prefix "expected". For example: Custom prefixes can be specified as a comma-separated sequence. Each prefix must start with a letter and contain only alphanumeric characters, hyphens, and underscores. For example, given just "-verify=foo,bar", the above diagnostic would be ignored, but the following diagnostics would be recognized: Multiple occurrences accumulate prefixes. For example, "-verify -verify=foo,bar -verify=baz" is equivalent to "-verify=expected,foo,bar,baz". SPECIFYING DIAGNOSTICS: Indicating that a line expects an error or a warning is simple. Put a comment on the line that has the diagnostic, use: to tag if it's an expected error, remark or warning, and place the expected text between {{ and }} markers. The full text doesn't have to be included, only enough to ensure that the correct diagnostic was emitted. Here's an example: You can place as many diagnostics on one line as you wish. To make the code more readable, you can use slash-newline to separate out the diagnostics. Alternatively, it is possible to specify the line on which the diagnostic should appear by appending "@<line>" to "expected-<type>", for example: The line number may be absolute (as above), or relative to the current line by prefixing the number with either '+' or '-'. If the diagnostic is generated in a separate file, for example in a shared header file, it may be beneficial to be able to declare the file in which the diagnostic will appear, rather than placing the expected-* directive in the actual file itself. This can be done using the following syntax: The path can be absolute or relative and the same search paths will be used as for #include directives. The line number in an external file may be substituted with '*' meaning that any line number will match (useful where the included file is, for example, a system header where the actual line number may change and is not critical). As an alternative to specifying a fixed line number, the location of a diagnostic can instead be indicated by a marker of the form "#<marker>". Markers are specified by including them in a comment, and then referenced by appending the marker to the diagnostic with "@#<marker>": The name of a marker used in a directive must be unique within the compilation. The simple syntax above allows each specification to match exactly one error. You can use the extended syntax to customize this. The extended syntax is "expected-<type> <n> {{diag text}}", where < type> is one of "error", "warning" or "note", and < n> is a positive integer. This allows the diagnostic to appear as many times as specified. Example: Where the diagnostic is expected to occur a minimum number of times, this can be specified by appending a '+' to the number. Example: In the first example, the diagnostic becomes optional, i.e. it will be swallowed if it occurs, but will not generate an error if it does not occur. In the second example, the diagnostic must occur at least once. As a short-hand, "one or more" can be specified simply by '+'. Example: A range can also be specified by "<n>-<m>". Example: In this example, the diagnostic may appear only once, if at all. Regex matching mode may be selected by appending '-re' to type and including regexes wrapped in double curly braces in the directive, such as: Examples matching error: "variable has incomplete type 'struct s'" VerifyDiagnosticConsumer expects at least one expected-* directive to be found inside the source code. If no diagnostics are expected the following directive can be used to indicate this:

Declared at: clang/include/clang/Frontend/VerifyDiagnosticConsumer.h:186

Inherits from: DiagnosticConsumer, CommentHandler

Member Variables

private clang::DiagnosticsEngine& Diags
private clang::DiagnosticConsumer* PrimaryClient
private std::unique_ptr<DiagnosticConsumer> PrimaryClientOwner
private std::unique_ptr<TextDiagnosticBuffer> Buffer
private std::unique_ptr<MarkerTracker> Markers
private const clang::Preprocessor* CurrentPreprocessor = nullptr
private const clang::LangOptions* LangOpts = nullptr
private clang::SourceManager* SrcManager = nullptr
private unsigned int ActiveSourceFiles = 0
private clang::VerifyDiagnosticConsumer::DirectiveStatus Status
private clang::VerifyDiagnosticConsumer::ExpectedData ED
private clang::VerifyDiagnosticConsumer::ParsedFilesMap ParsedFiles
private clang::VerifyDiagnosticConsumer::UnparsedFilesMap UnparsedFiles

Inherited from DiagnosticConsumer:

protected NumWarnings = 0
protected NumErrors = 0

Method Overview

Inherited from CommentHandler:

Inherited from DiagnosticConsumer:

Methods

void BeginSourceFile(
    const clang::LangOptions& LangOpts,
    const clang::Preprocessor* PP)

Description

Callback to inform the diagnostic client that processing of a source file is beginning. Note that diagnostics may be emitted outside the processing of a source file, for example during the parsing of command line options. However, diagnostics with source range information are required to only be emitted in between BeginSourceFile() and EndSourceFile().

Declared at: clang/include/clang/Frontend/VerifyDiagnosticConsumer.h:304

Parameters

const clang::LangOptions& LangOpts
The language options for the source file being processed.
const clang::Preprocessor* PP
The preprocessor object being used for the source; this is optional, e.g., it may not be present when processing AST source files.

void CheckDiagnostics()

Declared at: clang/include/clang/Frontend/VerifyDiagnosticConsumer.h:272

void EndSourceFile()

Description

Callback to inform the diagnostic client that processing of a source file has ended. The diagnostic client should assume that any objects made available via BeginSourceFile() are inaccessible.

Declared at: clang/include/clang/Frontend/VerifyDiagnosticConsumer.h:307

bool HandleComment(clang::Preprocessor& PP,
                   clang::SourceRange Comment)

Declared at: clang/include/clang/Frontend/VerifyDiagnosticConsumer.h:323

Parameters

clang::Preprocessor& PP
clang::SourceRange Comment

void HandleDiagnostic(
    DiagnosticsEngine::Level DiagLevel,
    const clang::Diagnostic& Info)

Description

Handle this diagnostic, reporting it to the user or capturing it to a log as needed. The default implementation just keeps track of the total number of warnings and errors.

Declared at: clang/include/clang/Frontend/VerifyDiagnosticConsumer.h:325

Parameters

DiagnosticsEngine::Level DiagLevel
const clang::Diagnostic& Info

void UpdateParsedFileStatus(
    clang::SourceManager& SM,
    clang::FileID FID,
    clang::VerifyDiagnosticConsumer::ParsedStatus
        PS)

Description

Update lists of parsed and unparsed files.

Declared at: clang/include/clang/Frontend/VerifyDiagnosticConsumer.h:321

Parameters

clang::SourceManager& SM
clang::FileID FID
clang::VerifyDiagnosticConsumer::ParsedStatus PS

VerifyDiagnosticConsumer(
    clang::DiagnosticsEngine& Diags)

Description

Create a new verifying diagnostic client, which will issue errors to the currently-attached diagnostic client when a diagnostic does not match what is expected (as indicated in the source file).

Declared at: clang/include/clang/Frontend/VerifyDiagnosticConsumer.h:301

Parameters

clang::DiagnosticsEngine& Diags

void setSourceManager(clang::SourceManager& SM)

Declared at: clang/include/clang/Frontend/VerifyDiagnosticConsumer.h:274

Parameters

clang::SourceManager& SM

~VerifyDiagnosticConsumer()

Declared at: clang/include/clang/Frontend/VerifyDiagnosticConsumer.h:302