[Clang] Fix : More Detailed "No expected directives found" (#78338)

Updated the error message to use the proper prefix when
no expected directives are found by changing the hard coded expected in

[Clang] Fix : More Detailed "No expected directives found" (#78338)

Updated the error message to use the proper prefix when
no expected directives are found by changing the hard coded expected in
the message to a dynamic value in two error messages.

Fixes #58290

show more ...

[Clang] Wide delimiters ('{{{') for expect strings (#77326)

Prior to this commit, it was impossible to use the simple string
matching directives to look for any content that contains unbalanced
`{

[Clang] Wide delimiters ('{{{') for expect strings (#77326)

Prior to this commit, it was impossible to use the simple string
matching directives to look for any content that contains unbalanced
`{{` `}}` pairs, such as:

```
// expected-note {{my_struct{{1}, 2}}}
```

Which would parse like so:

```
"nested" brace v
// expected-note {{my_struct{{1}, 2}}}
closes the nested brace ^ |
trailing }
```

And the frontend would complain 'cannot find end ('}}') of expected'.

At this snapshot, VerifyDiagnosticConsumer's parser now counts the
opening braces and looks for a matching length of closing sigils,
allowing the above to be written as:

```
// expected-note {{{my_struct{{1}, 2}}}}
opening brace |-| |-|
closing brace is '}}}', found here ^
```

This came about as a result of this discussion:
https://github.com/llvm/llvm-project/pull/74852#discussion_r1443117644

cc @erichkeane

show more ...

[clang][Verify] Show prefix in -verify error messages

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

Provide -verify support to match "any" line for diagnostics in included files.

Allow diagnostic checks that originate in included files to be matched without necessarily determining the line number

Provide -verify support to match "any" line for diagnostics in included files.

Allow diagnostic checks that originate in included files to be matched without necessarily determining the line number that the diagnostic occurs on. The new syntax replaces the line number with '*'. This extension is limited to diagnostics in included files and may be used where the include file is not part of the test-suite itself.

Expected uses are for diagnostics originating in system headers, or for users who use -verify in testing 3rd-party library code where the location of diagnostics in header files may change from revision to revision and their precise location is not important to the success of the test-case.

llvm-svn: 212735

show more ...

Fix "existant" typos

llvm-svn: 193578

[tests] Use 'printf' instead of 'echo -e', which is not part of BSD echo.

llvm-svn: 189562

Add 'not' to commands that are expected to fail.

This is at least good documentation, but also opens the possibility of
using pipefail.

llvm-svn: 185652

Extended VerifyDiagnosticConsumer to also verify source file for diagnostic.

VerifyDiagnosticConsumer previously would not check that the diagnostic and
its matching directive referenced the same so

Extended VerifyDiagnosticConsumer to also verify source file for diagnostic.

VerifyDiagnosticConsumer previously would not check that the diagnostic and
its matching directive referenced the same source file. Common practice was
to create directives that referenced other files but only by line number,
and this led to problems such as when the file containing the directive
didn't have enough lines to match the location of the diagnostic in the
other file, leading to bizarre file formatting and other oddities.

This patch causes VerifyDiagnosticConsumer to match source files as well as
line numbers. Therefore, a new syntax is made available for directives, for
example:

// expected-error@file:line {{diagnostic message}}

This extends the @line feature where "file" is the file where the diagnostic
is generated. The @line syntax is still available and uses the current file
for the diagnostic. "file" can be specified either as a relative or absolute
path - although the latter has less usefulness, I think! The #include search
paths will be used to locate the file and if it is not found an error will be
generated.

The new check is not optional: if the directive is in a different file to the
diagnostic, the file must be specified. Therefore, a number of test-cases
have been updated with regard to this.

This closes out PR15613.

llvm-svn: 179677

show more ...

Change VerifyDiagnosticConsumer so that it *must* contain at least one "expected-*" directive. As a result, for test-cases that are not expected to generate any diagnostics, an additional directive

Change VerifyDiagnosticConsumer so that it *must* contain at least one "expected-*" directive. As a result, for test-cases that are not expected to generate any diagnostics, an additional directive "expected-no-diagnostics" has been implemented which can then be included in such test-cases. This new directive may not be used in conjunction with any other "expected-*" directive.

This change was initially proposed as a solution to the problem highlighted by check-in r164677, i.e. that -verify will not cause a test-case failure where the compile command does not actually reference the file.

Patch reviewed by David Blaikie.

llvm-svn: 166281

show more ...

Fix directive parsing in VerifyDiagnosticConsumer so that it ensures that "expected" is at the start of the word and will no longer accept typos such as "junkexpected-*" as a valid "expected-*" direc

Fix directive parsing in VerifyDiagnosticConsumer so that it ensures that "expected" is at the start of the word and will no longer accept typos such as "junkexpected-*" as a valid "expected-*" directive. A very few test-cases had to be amended to adhere to the new rule.

Patch reviewed by David Blaikie.

llvm-svn: 166279

show more ...

Update VerifyDiagnosticConsumer to only get directives during parsing.

The old behavior was to re-scan any files (like modules) where we may have
directives but won't actually be parsing during the

Update VerifyDiagnosticConsumer to only get directives during parsing.

The old behavior was to re-scan any files (like modules) where we may have
directives but won't actually be parsing during the -verify invocation.
Now, we keep the old behavior in Debug builds as a sanity check (though
modules are a known entity), and expect all legitimate directives to come
from comments seen by the preprocessor.

This also affects the ARC migration tool, which captures diagnostics in
order to filter some out. This change adds an explicit cleanup to
CaptureDiagnosticsConsumer in order to let its sub-consumer handle the
real end of diagnostics.

This was originally split into four patches, but the tests do not run
cleanly without all four, so I've combined them into one commit.

Patches by Andy Gibbs, with slight modifications from me.

llvm-svn: 161650

show more ...

Allow -verify directives to be filtered by preprocessing.

This is accomplished by making VerifyDiagnosticsConsumer a CommentHandler,
which then only reads the -verify directives that are actually in

Allow -verify directives to be filtered by preprocessing.

This is accomplished by making VerifyDiagnosticsConsumer a CommentHandler,
which then only reads the -verify directives that are actually in live
blocks of code. It also makes it simpler to handle -verify directives that
appear in header files, though we still have to manually reparse some files
depending on how they are generated.

This requires some test changes. In particular, all PCH tests now have their
-verify directives outside the "header" portion of the file, using the @line
syntax added in r159978. Other tests have been modified mostly to make it
clear what is being tested, and to prevent polluting the expected output with
the directives themselves.

Patch by Andy Gibbs! (with slight modifications)

The new Frontend/verify-* tests exercise the functionality of this commit,
as well as r159978, r159979, and r160053 (Andy's other -verify enhancements).

llvm-svn: 160068

show more ...