[Mesa-dev] [PATCH 3/3] glsl: remove out of date comments from file header
Timothy Arceri
timothy.arceri at collabora.com
Thu Feb 11 04:45:07 UTC 2016
The bison/flex generated code hasn't been keeped in version control
for a long time, and I doubt anyone is going to argue for putting
all this validation in the parser.
---
src/compiler/glsl/ast_to_hir.cpp | 18 +-----------------
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index b558589..fc0d448 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -23,7 +23,7 @@
/**
* \file ast_to_hir.c
- * Convert abstract syntax to to high-level intermediate reprensentation (HIR).
+ * Convert abstract syntax to high-level intermediate reprensentation (HIR).
*
* During the conversion to HIR, the majority of the symantic checking is
* preformed on the program. This includes:
@@ -31,22 +31,6 @@
* * Symbol table management
* * Type checking
* * Function binding
- *
- * The majority of this work could be done during parsing, and the parser could
- * probably generate HIR directly. However, this results in frequent changes
- * to the parser code. Since we do not assume that every system this complier
- * is built on will have Flex and Bison installed, we have to store the code
- * generated by these tools in our version control system. In other parts of
- * the system we've seen problems where a parser was changed but the generated
- * code was not committed, merge conflicts where created because two developers
- * had slightly different versions of Bison installed, etc.
- *
- * I have also noticed that running Bison generated parsers in GDB is very
- * irritating. When you get a segfault on '$$ = $1->foo', you can't very
- * well 'print $1' in GDB.
- *
- * As a result, my preference is to put as little C code as possible in the
- * parser (and lexer) sources.
*/
#include "glsl_symbol_table.h"
--
2.5.0
More information about the mesa-dev
mailing list