Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-12-03T19:21:13+00:00 2019-12-03T19:21:13+00:00 Joel E. Denny jdenny.ornl@gmail.com 2019-12-03T15:13:00+00:00 urn:sha1:fdde18a7c3e5ae62f458fb83230ec340bf658668 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-11-21T23:01:12+00:00 Joel E. Denny jdenny.ornl@gmail.com 2019-11-20T22:12:29+00:00 urn:sha1:f471eb8e99b564265a4bea326922263ff06cda40 Without this patch, `FILECHECK_OPTS` isn't propagated to FileCheck's test suite so that `FILECHECK_OPTS` doesn't inadvertently affect test results by affecting the output of FileCheck calls under test. As a result, `FILECHECK_OPTS` is useless for debugging FileCheck's test suite. In `llvm/test/FileCheck/lit.local.cfg`, this patch provides a new subsitution, `%ProtectFileCheckOutput`, to address this problem for both `FILECHECK_OPTS` and the deprecated `FILECHECK_DUMP_INPUT_ON_FAILURE`. The rest of the patch uses `%ProtectFileCheckOutput` throughout the test suite Fixes PR40284. Reviewed By: probinson, thopre Differential Revision: https://reviews.llvm.org/D65121 2019-11-19T17:08:54+00:00 Joel E. Denny jdenny.ornl@gmail.com 2019-11-19T15:54:21+00:00 urn:sha1:6e418decd936a3e22dec5cebc77ecb86dc7f37c3 An advantage is that there are less portability concerns when writing tests. For example, `-u` is not supported by all implementations of `env`, but lit's internal shell provides its own `env` that supports `-u`. A disadvantage is that some shell constructs, such as parentheses, are not supported, but FileCheck's test suite currently doesn't require such constructs. For comparison, lit configures its test suite in the same manner. See `llvm/utils/lit/tests/lit.cfg`. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D70278 2019-10-11T11:59:14+00:00 Kai Nacke kai.nacke@redstar.de 2019-10-11T11:59:14+00:00 urn:sha1:5b5b2fd2b8b4fe66d1e57065ab0aef22b16e4a13 The FileCheck utility is enhanced to support a `--ignore-case` option. This is useful in cases where the output of Unix tools differs in case (e.g. case not specified by Posix). Reviewers: Bigcheese, jakehehrlich, rupprecht, espindola, alexshap, jhenderson, MaskRay Differential Revision: https://reviews.llvm.org/D68146 llvm-svn: 374538 2019-10-10T14:27:14+00:00 Dmitri Gribenko gribozavr@gmail.com 2019-10-10T14:27:14+00:00 urn:sha1:d3aed7fc7986971ea15313871e7ffe8b4a5efa18 This reverts commit r374339. It broke tests: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/19066 llvm-svn: 374359 2019-10-10T13:15:41+00:00 Kai Nacke kai.nacke@redstar.de 2019-10-10T13:15:41+00:00 urn:sha1:dfd2b6f07fc40a190335f580d8a965bbebfe94df The FileCheck utility is enhanced to support a `--ignore-case` option. This is useful in cases where the output of Unix tools differs in case (e.g. case not specified by Posix). Reviewers: Bigcheese, jakehehrlich, rupprecht, espindola, alexshap, jhenderson, MaskRay Differential Revision: https://reviews.llvm.org/D68146 llvm-svn: 374339 2019-09-02T14:04:00+00:00 Thomas Preud'homme thomasp@graphcore.ai 2019-09-02T14:04:00+00:00 urn:sha1:a291b950dbd9887e3b9162951b81fcdd71927756 Summary: Commit r366897 introduced the possibility to set a variable from an expression, such as [[#VAR2:VAR1+3]]. While introducing this feature, it introduced extra logic to allow using such a variable on the same line later on. Unfortunately that extra logic is flawed as it relies on a mapping from variable to expression defining it when the mapping is from variable definition to expression. This flaw causes among other issues PR42896. This commit avoids the problem by forbidding all use of a variable defined on the same line, and removes the now useless logic. Redesign will be done in a later commit because it will require some amount of refactoring first for the solution to be clean. One example is the need for some sort of transaction mechanism to set a variable temporarily and from an expression and rollback if the CHECK pattern does not match so that diagnostics show the right variable values. Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk Subscribers: JonChesterfield, rogfer01, hfinkel, kristina, rnk, tra, arichardson, grimar, dblaikie, probinson, llvm-commits, hiraditya Tags: #llvm Differential Revision: https://reviews.llvm.org/D66141 llvm-svn: 370663 2019-08-14T02:56:09+00:00 Joel E. Denny jdenny.ornl@gmail.com 2019-08-14T02:56:09+00:00 urn:sha1:608f2bfd65ec14debe22bce8179ffe2b514b4e91 Without this patch, `-dump-input` prints a diagnostic at the end of its marker range. For example: ``` 1: Start. check:1 ^~~~~~ 2: Bad. next:2 X~~~ 3: Many lines next:2 ~~~~~~~~~~ 4: of input. next:2 ~~~~~~~~~ 5: End. next:2 ~~~~ error: no match found ``` This patch moves it to the beginning like this: ``` 1: Start. check:1 ^~~~~~ 2: Bad. next:2 X~~~ error: no match found 3: Many lines next:2 ~~~~~~~~~~ 4: of input. next:2 ~~~~~~~~~ 5: End. next:2 ~~~~ ``` The former somehow looks nicer because the diagnostic doesn't appear to be somewhere within the marker range. However, the latter is more practical, especially when the marker range includes the remainder of a very long dump. First, in the case of an error, this patch enables me to search the dump for `error:` and usually immediately land where the detected error began. Second, when trying to follow FileCheck's logic, it's best to read top down, so this patch enables me to see each diagnostic as soon as I encounter its marker. Reviewed By: thopre Differential Revision: https://reviews.llvm.org/D65702 llvm-svn: 368786 2019-07-24T12:38:29+00:00 Thomas Preud'homme thomasp@graphcore.ai 2019-07-24T12:38:29+00:00 urn:sha1:a83dfd92bef4ffdc08765a20dffa1e29d194d618 Summary: Testing of caret location in diagnostic message is currently made with CHECK directive with the following general format: CHECK: {{^ \^$}} James Henderson suggested the following would be more readable: CHECK: {{^}} ^{{$}} and when whole lines can be matched (as is the case for command-line testing where error messages do not include path): CHECK: ^ using the option --match-full-lines. This commit implements these 2 changes on all existing caret position tests. It also aligns the caret to the character it is trying to match in the above line. Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk Subscribers: JonChesterfield, rogfer01, hfinkel, kristina, rnk, tra, arichardson, grimar, dblaikie, probinson, llvm-commits, hiraditya Tags: #llvm Differential Revision: https://reviews.llvm.org/D64923 > llvm-svn: 366861 llvm-svn: 366898 2019-07-24T12:38:22+00:00 Thomas Preud'homme thomasp@graphcore.ai 2019-07-24T12:38:22+00:00 urn:sha1:4cd9b853b5ae3f569683cdba955cd70c39a7bbe7 Summary: This patch is part of a patch series to add support for FileCheck numeric expressions. This specific patch lift the restriction for a numeric expression to either be a variable definition or a numeric expression to try to match. This commit allows a numeric variable to be set to the result of the evaluation of a numeric expression after it has been matched successfully. When it happens, the variable is allowed to be used on the same line since its value is known at match time. It also makes use of this possibility to reuse the parsing code to parse a command-line definition by crafting a mirror string of the -D option with the equal sign replaced by a colon sign, e.g. for option '-D#NUMVAL=10' it creates the string '-D#NUMVAL=10 (parsed as [[#NUMVAL:10]])' where the numeric expression is parsed to define NUMVAL. This result in a few tests needing updating for the location diagnostics on top of the tests for the new feature. It also enables empty numeric expression which match any number without defining a variable. This is done here rather than in commit #5 of the patch series because it requires to dissociate automatic regex insertion in RegExStr from variable definition which would make commit #5 even bigger than it already is. Copyright: - Linaro (changes up to diff 183612 of revision D55940) - GraphCore (changes in later versions of revision D55940 and in new revision created off D55940) Reviewers: jhenderson, chandlerc, jdenny, probinson, grimar, arichardson, rnk Subscribers: hiraditya, llvm-commits, probinson, dblaikie, grimar, arichardson, tra, rnk, kristina, hfinkel, rogfer01, JonChesterfield Tags: #llvm Differential Revision: https://reviews.llvm.org/D60388 > llvm-svn: 366860 llvm-svn: 366897