On Mon, Nov 26, 2012 at 3:40 PM, Anuj Phogat <anuj.pho...@gmail.com> wrote: > On Mon, Nov 26, 2012 at 2:30 PM, Matt Turner <matts...@gmail.com> wrote: >> This is at least better than failing to compile the shader. >> > I agree. >> I think this is a pretty clear indication that app developers think >> these macros are about as useful as the rest of us. >> >> Works around es3conform's silly preprocess2_frag and preprocess16_frag >> tests. >> --- >> src/glsl/glcpp/README | 4 ++-- >> src/glsl/glcpp/glcpp-parse.y | 3 +++ >> 2 files changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/src/glsl/glcpp/README b/src/glsl/glcpp/README >> index 0b5ef50..592d073 100644 >> --- a/src/glsl/glcpp/README >> +++ b/src/glsl/glcpp/README >> @@ -25,8 +25,8 @@ and will not appear in the output. >> >> Known limitations >> ----------------- >> -The __LINE__ and __FILE__ macros are not yet supported. >> +The __LINE__ and __FILE__ macros always evaluate to zero. >> >> A file that ends with a function-like macro name as the last >> non-whitespace token will result in a parse error, (where it should be >> -passed through as is). >> \ No newline at end of file >> +passed through as is). > This change looks unnecessary.
Yeah, it's not intentional, but I'm not sure how to make vim not do that. I'm also not sure that leaving off the final newline was intentional. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
