glcpp: Only warn for macro names containing __

Section 3.3 (Preprocessor) of the GLSL 1.30 spec (and later) and the
GLSL ES spec (all versions) say:

    "All macro names containing two consecutive underscores ( __ ) are
    reserved for future use as predefined macro names. All macro names
    prefixed with "GL_" ("GL" followed by a single underscore) are also
    reserved."

The intention is that names containing __ are reserved for internal use
by the implementation, and names prefixed with GL_ are reserved for use
by Khronos.  Since every extension adds a name prefixed with GL_ (i.e.,
the name of the extension), that should be an error.  Names simply
containing __ are dangerous to use, but should be allowed.  In similar
cases, the C++ preprocessor specification says, "no diagnostic is
required."

Per the Khronos bug mentioned below, a future version of the GLSL
specification will clarify this.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Tested-by: Darius Spitznagel <d.spitznagel@goodbytez.de>
Cc: Tapani Pälli <lemody@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870
Bugzilla: Khronos #11702

diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
index 5bb2891c47593164ffa4d8779fbd60f8476e054d..bdc598f31b8d7e6684472f3645964aa8e21371d4 100644 (file)
--- a/src/glsl/glcpp/glcpp-parse.y
+++ b/src/glsl/glcpp/glcpp-parse.y
@@ -1770,11 +1770,27 @@ static void
 _check_for_reserved_macro_name (glcpp_parser_t *parser, YYLTYPE *loc,
                                const char *identifier)
 {
-       /* According to the GLSL specification, macro names starting with "__"
-        * or "GL_" are reserved for future use.  So, don't allow them.
+       /* Section 3.3 (Preprocessor) of the GLSL 1.30 spec (and later) and
+        * the GLSL ES spec (all versions) say:
+        *
+        *     "All macro names containing two consecutive underscores ( __ )
+        *     are reserved for future use as predefined macro names. All
+        *     macro names prefixed with "GL_" ("GL" followed by a single
+        *     underscore) are also reserved."
+        *
+        * The intention is that names containing __ are reserved for internal
+        * use by the implementation, and names prefixed with GL_ are reserved
+        * for use by Khronos.  Since every extension adds a name prefixed
+        * with GL_ (i.e., the name of the extension), that should be an
+        * error.  Names simply containing __ are dangerous to use, but should
+        * be allowed.
+        *
+        * A future version of the GLSL specification will clarify this.
         */
        if (strstr(identifier, "__")) {
-               glcpp_error (loc, parser, "Macro names containing \"__\" are reserved.\n");
+               glcpp_warning(loc, parser,
+                             "Macro names containing \"__\" are reserved "
+                             "for use by the implementation.\n");
        }
        if (strncmp(identifier, "GL_", 3) == 0) {
                glcpp_error (loc, parser, "Macro names starting with \"GL_\" are reserved.\n");

diff --git a/src/glsl/glcpp/tests/086-reserved-macro-names.c.expected b/src/glsl/glcpp/tests/086-reserved-macro-names.c.expected
index d8aa9f0a64848cfe195693d490aff7c79aabebf6..5ca42a983a4d4386151b17540a0bb2e449c7509c 100644 (file)
--- a/src/glsl/glcpp/tests/086-reserved-macro-names.c.expected
+++ b/src/glsl/glcpp/tests/086-reserved-macro-names.c.expected
@@ -1,8 +1,8 @@
-0:1(10): preprocessor error: Macro names containing "__" are reserved.
+0:1(10): preprocessor warning: Macro names containing "__" are reserved for use by the implementation.
 
 0:2(9): preprocessor error: Macro names starting with "GL_" are reserved.
 
-0:3(9): preprocessor error: Macro names containing "__" are reserved.
+0:3(9): preprocessor warning: Macro names containing "__" are reserved for use by the implementation.