only declare compatibility gl_ variables in compatibility mode #2664
+62
−67
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
avoid declaring them in GLSL 1.50+ if core profile is chosen by the version statement
fixes #2663
It seems like the ARBCompatibility variable is meant to act as if the hosting GL context was created with WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB. However I think this should only be inherited into the GLSL compiler for GLSL 1.40. 1.50+ should use what is declared by the #version statement.
For the test cases that were changed, here are my thoughts:
430scope.vert
cppSimple.vert
link.multiAnonBlocksInvalid.0.0.vert
link.multiAnonBlocksValid.0.0.vert
link.multiBlocksInvalid.0.0.vert
link.multiBlocksValid.1.0.vert
versionsErrors.vert:
New output seems correct, the variables are just no longer declared:
150.vert:
core profile - gl_ClipVertex shouldn't be declared, new error is correct.
150.frag:
not sure why we lost an error message here, seem like the extra error was superfluous anyways.
400.frag:
core profile - gl_Color shouldn't even exist, previous redeclaration error makes no sense.
450.vert:
not sure about this one.
specExamples.frag:
specExamples.vert:
I don't see why was these were considered valid code. They are both core profile, so using the deprecated variables should have been an error.