This change adds GLSLANG_EXPORT in a couple more places, as well as
adding a new symbol visibility annotation GLSLANG_EXPORT_FOR_TESTS which
is defined the same as GLSLANG_EXPORT but documents the intention that
the symbols marked with it are only meant to be used by glslang's test
suite and do not form part of the public API and are thus not subject to
ABI stability guarantees.
The TProgram::mapIO method takes a TIoMapResolver and a TIoMapper,
however the only way to obtain instances of these was from methods in
iomapper.h. Rather than try to expose that header as part of the API,
new methods are added to the public ShaderLang.h header to create a
TDefaultGlslIoResolver and a TGlslIoMapper and return them as pointers
to their respective base classes, which are defined in the public
header.
This patch tries to attach debug location of a branch/return instruction to its predecessor or the closing brace. If none could be found, no debug info should be emitted.
Don't report the following error when scanning inactive code (e.g. code inside #if 0):
"error: '#' : (#) can be preceded in its line only by spaces or horizontal tab"
Adds a variable to PpContext to say whether we're currently skipping over an inactive #if/#ifdef/#elif/#else, and don't report the error inside scanToken if true.
fixes 3704
The inVarMaps, outVarMaps, uniformVarMap, and intermediates arrays were
being memset with a size 1 bigger than their actual size. They are now
initialized correctly, which also allows making inVarMaps, outVarMaps,
and uniformVarMap into private members.
Remove the dependency on LiveTraverser.h, which transitively includes
localintermediate.h. As a result, some things have been moved from
iomapper.h to iomapper.cpp, specifically the TVarEntry type and the
constructor and destructor of TGlslIoMapper.
Earlier the comment looked misleading that composites of 8/16-bit types can't be constructed at all.
As per the GL_EXT_shader_16bit_storage extension, they can't be constructed directly, however, can be constructed indirectly.
If an 'in' is present in a shader stage, make sure a matching 'out'
is present in the previous stage. Only enabled when doing Vulkan.
This commit also fixes a bug where previous stage's linkerObjects
got polluted with 'in' variables from the next stage when merging
linker objects.
When location aliasing, the aliases sharing the location must have the same underlying numerical type and bit width (floating-point or integer, 32-bit versus 64-bit, etc.) and the same auxiliary storage and interpolation qualification.
This adds checks for the "patch" and "sample" qualifiers, and also relaxes the checks when the signedness of integer types differs.
This fixes a couple of integer overflows in parsing as well as removes
the construction of a null reference that never got dereferenced.
This also initializes the bool members in TCall
Finally, this adds a UBSAN run alongside ASAN and TSAN in CI.
[BugFix] Do not generate any conversion for 8-bit and 16-bit types if it is an identity conversion.
Earlier (before this fix), it generated incorrect SPIR-V convert instructions, as SPIR-V
requires that the types being converted differ.
* location aliasing
when location aliasing, the aliases sharing the location must have the same underlying numerical type
(floating-point or integer) and the same auxiliary storage and interpolation qualification.
The following case, glslang need report error.
layout(vertices = 1) out;
layout (location = 1, component = 0) in double gohan[];
layout (location = 1, component = 2) in float goten[];
in vec4 vs_tcs[];
out vec4 tcs_tes[];
void main()
{
}
* Need consider the following case: location aliasing with different interpolation qualifier.
Even for a double precision float, the largest valid exponent is 308, so
clamp exponents to 500 when parsing to avoid overflow of the parsed
exponent value if the exponent is too big.
coopmat<> type definition allows type parameters. To make it accept
types defined by spirv_type directive, we add spirvType info to the type
parameters. This change is to support this case. And a test is added to
show the missing usage.
The actual support has been available with GL_EXT_control_flow_attributes.
This change set is to handle
"#extension GL_EXT_control_flow_attributes2 : <val>"
Add support for GL_ARB_shading_language_include. Usage is identical to
the way GL_GOOGLE_include_directive currently works glslang (since
GL_ARB_shading_language_include is inherently a runtime feature and
glslang is an offline compiler).
Users can simulate their runtime environment by using a custom
glslang::TShader::Includer or using filenames that match their GL
runtime names.
Closes#249.
Since assert(0) compiles to nothing on release builds, it's not
sufficient to silence a fallthrough warning. Instead, some switch
statements are changed into if/else and others have the assert(0)
replaced with "return 0".
This is intended so that downstream projects consuming glslang with FetchContent or similar means can use `-Wimplicit-fallthrough` without getting warning spam.
I've used my best judgement to determine whether the implicit fallthrough was desired, or was simply unreachable code.
`std::unreachable` is unavailable until C++23, but I saw places where `default: assert(0);` was used, so copied that.
There were a few places where some code might actually have been reachable and intended to return a value that represented an error, so someone should double check that kind of thing.
Like with the last few PRs from me, it fixes a warning that's commonly enabled in downstream projects that might want to consume glslang via FetchContent or equivalent.
It doesn't actually enable the warning, but that might be desirable.
I think I found a bug in the Spv.FromFile.cpp tests that would have been prevented had this warning been enabled all along.
I had to guess the value for the missing field, so went for the most common one in the list.
The only test case that used a different value before had an RWTexture1D, so if baseImageBinding is meaning the same kind of image as image load store in OpenGL, it would make sense that that would be the only one to need a non-zero value for the binding.
I'm a little concerned that the test wasn't previously failing with the incorrectly-assigned fields as it implies they don't make any difference, so the test might be too permissive.
Co-authored-by: Neil Hickey <neil.hickey@arm.com>
Co-authored-by: Stuart Brady <stuart.brady@arm.com>
Signed-off-by: Sven van Haastregt <sven.vanhaastregt@arm.com>
