Should enabling extensions raise errors ?

[rcmz]

Enabling GL_EXT_mesh_shader in a non mesh / task shader raises an error. Should it ? it is the only extension that does it (trust me, I tested it !). Most extensions just do nothing, and a few raise a warning, which feels like the right behavior.

WARNING: /home/rcmz/Projects/shaderV3demos/shaderV3/includeGLSL/extensions.comp:11: '#extension' : extension not supported: GL_KHR_shader_subgroup
WARNING: /home/rcmz/Projects/shaderV3demos/shaderV3/includeGLSL/extensions.comp:30: '#extension' : extension not supported: GL_KHR_shader_subgroup
WARNING: /home/rcmz/Projects/shaderV3demos/shaderV3/includeGLSL/extensions.comp:42: '#extension' : extension not supported: GL_EXT_subgroupuniform_qualifier
WARNING: /home/rcmz/Projects/shaderV3demos/shaderV3/includeGLSL/extensions.comp:53: '#extension' : extension not supported: GL_EXT_shader_subgroup_extended_types
WARNING: /home/rcmz/Projects/shaderV3demos/shaderV3/includeGLSL/extensions.comp:61: '#extension' : extension not supported: GL_NV_primitive_shading_rate
WARNING: /home/rcmz/Projects/shaderV3demos/shaderV3/includeGLSL/extensions.comp:63: '#extension' : extension not supported: GL_HUAWEI_subpass_shading
ERROR: /home/rcmz/Projects/shaderV3demos/shaderV3/includeGLSL/extensions.comp:67: '#extension GL_EXT_mesh_shader' : not supported in this stage: compute

Citing (and abbreviating) the GLSL spec :
Directives to control the behavior of the compiler with respect to extensions are declared with the #extension directive
#extension extension_name : behavior
Behavior Effect :
require Give a compile-time error on the #extension if the extension extension_name is not supported.
enable Warn on the #extension if the extension extension_name is not supported.

[arcady-lunarg]

I think you're right, this is indeed a bug. All the extension declaration should do is raise an error or warning if the extension is not supported and enable the keywords and functions and variables that are specified by that extension. There's an internal function requireStage in glslang that meant to check when a feature is being used in a shader stage where it's not supported, and almost all checks are from when some feature is being encountered in a potentially inapplicable shader stage, this is the only case where the check is on the use of the extension itself. This is also how this extension should be handled and while requiring the extension on an inappropriate shader stage won't do anything useful (since the extension specifies no new features for, say, compute shaders) it should serve as an assertion that the GLSL implementation (i.e. glslang) does support the extension.

All that said, it's been like this for a while and fixing this is probably not going to be a super high priority. If you want to write a patch I'll be happy to review it though.

[rcmz]

I agree that this is a low priority bug. I might try to fix it when I have time.