Androïd/x86 port of Mesa drivers https://git.hiegel.fr/cgit/android-x86-mesa.git/atom?h=android-x86-2.2 2010-08-23T17:48:10Z 2010-08-23T17:48:10Z Carl Worth cworth@cworth.org 2010-08-23T17:41:30Z urn:sha1:21560c40e8aa98624a225752b98babc7ae2938d5 We recently added several tests that intentionally trigger preprocessor errors. During valgrind-based testing, our test script was noticing the non-zero return value from the preprocessor and incorrectly flagging the valgrind-based test as failing. To fix this, we make valgrind return an error code that is otherwise unused by the preprocessor. 2010-08-23T17:48:10Z Carl Worth cworth@cworth.org 2010-08-23T16:26:44Z urn:sha1:2a9e791fdeb45080a98042d41c153ea19c17caae This test exposes two current bugs: 1. The source number is not being correctly emitted in error messages (instead, it's always 0). 2. A directive of "#line 0" is resulting in the following parse error: preprocessor error: Invalid tokens after # 2010-08-23T17:48:10Z Carl Worth cworth@cworth.org 2010-08-23T15:54:06Z urn:sha1:0acd68c4050fea82797f80ad90212926df4cf001 This directive is already implemented nicely, but wasn't previously tested. It will be convenient to use this directive in further tests that rely on error messages, (such as ensuring that #line correctly sets the line number in the error message). 2010-08-18T06:41:53Z Carl Worth cworth@cworth.org 2010-08-18T06:19:01Z urn:sha1:105e2137d67b98c24251be3586985fb61aeaf28a The specification says that redefining a macro is an error, unless the new definitions is identical to the old one, (identical replacement lists but ignoring differing amounts of whitespace). 2010-08-18T05:23:43Z Carl Worth cworth@cworth.org 2010-08-18T05:23:43Z urn:sha1:ce5d0a296c984a9b746f0b248f4cb10ed78bc647 In commit 6be3a8b70af4ba4fa4d037d54ecf6d5f055edbc9, the #version directive was fixed to stop generating a spurious newline. Here we simply update the expected result for the single test which includes a #version directive. 2010-08-18T00:51:10Z Eric Anholt eric@anholt.net 2010-08-18T00:50:05Z urn:sha1:ede67e307142000a408e40b637132700a4dc2808 2010-08-11T21:38:04Z Carl Worth cworth@cworth.org 2010-08-11T21:09:11Z urn:sha1:da6b10a7eb26c8a13056cbae9015d5b84f134142 This was previously being appended to the output string *after* a copy of the supposedly final string was made and handed to the caller. So the diagnostic was never actually visible to the user. We fix this by moving the check for an unterminated #if from glcpp_parser_destroy to the calling function, preprocess. This fixes the test case 083-unterminated-if.c. 2010-08-11T21:38:04Z Carl Worth cworth@cworth.org 2010-08-11T20:59:22Z urn:sha1:253cad3f424f71f6984431e5edbde1694ccfae3f This is more clear than the previously-generated diagnostic which was something confusing like "enexpected newline". This change makse test 080-if-witout-expression.c now pass. 2010-08-11T21:38:03Z Carl Worth cworth@cworth.org 2010-08-11T20:50:51Z urn:sha1:624dd585c72103e5bffbc600cdf7bdfba5305a15 Rather than telling the user what to fix, the standard convention is to describe what the detected problem is. With this change, test 081-elif-without-expression now passes. 2010-08-11T21:38:03Z Carl Worth cworth@cworth.org 2010-08-11T20:48:13Z urn:sha1:cb5ea0c79bd74ea6263d54302ed19c243ceb05de Which are proving to be useful since some of these tests are not yet acting as desired, (in particular, the unterminated if test is not generating any diagnostic).