Inside the grammar for function_identifier if the .function is null an
empty function name is allocated. This is allocated on the stack and
passed into TFunction as a pointer. TFunction just stores that pointer.
Later, when we access the name we will receive an invalid usage of a
stack allocated variable. This CL switches to using NewPoolTStringn for
the empty function name.
This fixes the comparison in macro body redefinitions, where initial
white-space differences do not matter, but internal white-space differences
do matter.
This has been a continually fragile area. Switching to a vector of real
objects, instead of a linearized stream of characters, removes a bunch of
code and generally makes this area more robust.
- This change also allows redeclaration of gl_PrimitiveIndicesNV and
adds error checks against incorrect explicit array size.
- Also modifies gtests to check array bound limits and redeclare gl_PrimitiveIndicesNV[].
* This comes from the resolution of issues 4, 5 & 6 in
ARB_program_interface_query, stating that uniform buffers should have their
members expanded out as normal and arrays should have elements added.
* If a buffer block has a large array e.g. [10000] we don't want to iterate over
every array element. Instead we should only expand out the first [0] element,
then expand as normal from there.
* The array name should still be appended with [0] to indicate that it's an
array.
In MSVC 2017 Debug mode when a reflection is deleted (when a shader goes out of scope) xutility will fail to clear the children due to the TString allocator implementation. By switching to std::string xutility no longer throws the error.
This commit undoes the code on the commit "ParseHelper: assign
xfb_offset for struct members too" (commit
af8c1bdb161e4b2ddf019b61bdfca61f84cb1ca8), except the method renaming,
and updates the tests.
During the review of the implementation of Vulkan extension
VK_EXT_transform_feedback for the Linux Intel driver, it was pointed
that the Vulkan environment spec for SPIR-V only ever refers to block
or block members being decorated. It would be strange to not do the
same for OpenGL (ARB_gl_spirv). That would also fit better to what
GLSL does, where setting explicit xfb offsets for struct members is
not allowed.
FWIW, the original patch was proposed based on the fact that
ARB_gl_spirv is relying on OpenGL for how xfb offsets should be
assigned to members, and it was not clear (at least to me) which is
the responsible of such.
* Previously the offset was only updated with EOpIndexDirectStruct, but we also
need to update it for the other index types into arrays, and when expanding an
aggregate reached after dereferencing.
