steve-lunarg a2b01a0da8 HLSL: Recursive composite flattening
This PR implements recursive type flattening.  For example, an array of structs of other structs
can be flattened to individual member variables at the shader interface.

This is sufficient for many purposes, e.g, uniforms containing opaque types, but is not sufficient
for geometry shader arrayed inputs.  That will be handled separately with structure splitting,
 which is not implemented by this PR.  In the meantime, that case is detected and triggers an error.

The recursive flattening extends the following three aspects of single-level flattening:

- Flattening of structures to individual members with names such as "foo[0].samp[1]";

- Turning constant references to the nested composite type into a reference to a particular
  flattened member.

- Shadow copies between arrays of flattened members and the nested composite type.

Previous single-level flattening only flattened at the shader interface, and that is unchanged by this PR.
Internally, shadow copies are, such as if the type is passed to a function.

Also, the reasons for flattening are unchanged.  Uniforms containing opaque types, and interface struct
types are flattened.  (The latter will change with structure splitting).

One existing test changes: hlsl.structin.vert, which did in fact contain a nested composite type to be
flattened.

Two new tests are added: hlsl.structarray.flatten.frag, and hlsl.structarray.flatten.geom (currently
issues an error until type splitting is online).

The process of arriving at the individual member from chained postfix expressions is more complex than
it was with one level.  See large-ish comment above HlslParseContext::flatten() for details.
2016-12-07 14:40:01 -07:00
..
2016-03-31 10:31:30 -04:00

Glslang Tests based on the Google Test Framework

This directory contains Google Test based test fixture and test cases for glslang.

Apart from typical unit tests, necessary utility methods are added into the GlslangTests fixture to provide the ability to do file-based integration tests. Various *.FromFile.cpp files lists names of files containing input shader code in the Test/ directory. Utility methods will load the input shader source, compile them, and compare with the corresponding expected output in the Test/baseResults/ directory.

How to run the tests

Please make sure you have a copy of Google Test checked out under the External directory before building. After building, just run the ctest command or the gtests/glslangtests binary in your build directory.

The gtests/glslangtests binary also provides an --update-mode command line option, which, if supplied, will overwrite the golden files under the Test/baseResults/ directory with real output from that invocation. This serves as an easy way to update golden files.