================
@@ -3647,6 +3702,153 @@ Examples matching error: "variable has incomplete type
'struct s'"
// expected-error-re {{variable has type 'struct {{(.*)}}'}}
// expected-error-re {{variable has type 'struct{{[[:space:]](.*)}}'}}
+Verifying the Directives
+~~~~~~~~~~~~~~~~~~~~~~~~
+Clang ``-cc1`` also has ``-verify-directives`` mode, which can be enabled
+alongside ``-verify`` to place additional restrictions on directives,
+and strives to improve readability of the expected compiler output
+for reviewers and future readers, but makes it a bit harder to write the test:
+
+- Diagnostic text specified in a directive has to be a full match.
+- Lexical order of directives has to match order in which diagnostics are
+ emitted.
+- Each directive can match exactly one diagnostic.
+- Wildcards (``*``) are not allowed in diagnostic location.
+
+It is recommended to write new tests with this mode enabled, but for some tests
+it's not possible. Typical problems and their solutions are listed below.
+
+- **Diagnostic is issued only sometimes.**
+ The cause of variance needs to be identified and captured. Typically it is
+ either a compiler option like language mode, in which case additional custom
+ prefix should be sufficient, or platform, in which case triple has to be
+ explicitly passed in command-line arguments.
+- **Template instantiations at the end of translation unit.**
+ Instantiations at the end of the TU cause associated diagnostics to appear
+ too late. Instantiations need to happen before the next directive, and when
+ it is possible, it still takes some creativity to achieve, especially in
+ C++98 mode. Typical solutions include explicit template instantiations,
+ manifestly constant-evaluated expressions, ``enable_if``, and removing
+ template parameters altogether.
+- **Analysis-based warnings.** Some warnings, like ``-Wunused``, are based
+ on CFG analysis and are emitted later than e.g. parser would emit them,
+ because some lookahead is required to collect all the necessary information
+ for such analysis. Not much can be done in this case.
+- **Lambdas.** When lambda is mentioned in diagnostic message, it is identified
+ by its source location, which is typically not salient for the test,
+ and would make it overspecified. In this case regex match can be used to skip
+ over source location.
+
+C++ Defect Report Tests
+^^^^^^^^^^^^^^^^^^^^^^^
+C++ Defect Report tests are placed in ``clang/test/CXX/drs`` directory, which
+consists of two types of files:
+
+- files where tests are grouped by 100 by issue number, e.g. ``cwg15xx.cpp``
+ ("big files");
+- files with individual tests or smaller groups of tests, e.g. ``cwg177x.cpp``
+ or ``cwg787.cpp``.
+
+C++ defect report tests are run in all language modes available via ``-std=``,
+except for modes with GNU extensions and ``c++03``, as it is synonymous to
+``c++98``. Exceptions, pedantic errors, and ``-verify-directives`` are enabled.
+
+Big files are where most of the tests end up being placed to save on process
+startup cost during test runs. Big files also serve as an index of tests:
+even if test is placed in its individual file, it's still mentioned in the
+big file where this test would be placed otherwise. Big files need all tests
+to work with the same set of compiler options specified in RUN lines, but
+sometimes tests need special provisions, in which case they should be placed
+in their own file. Typical reasons for that include:
+
+- **Test is checking AST dump or LLVM IR.** We don't yet know how
----------------
erichkeane wrote:
Isn't there the 'split-input-file' trick that folks in the backend do
constantly?
The easiest for me is here:
https://github.com/erichkeane/llvm-project/blob/51f2bb6552c9829ebe5d4888d1503a11645da2ef/mlir/test/Target/LLVMIR/llvmir.mlir
Though i wonder if we should have a similar flag in clang?
https://github.com/llvm/llvm-project/pull/179835
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
