Initial work on handling resources in structs during cross-compilation

- The basic idea is that during the "lowering" pass, some types (notably: aggregate types that contain resource variables) will get turned into "tuple" types, which are pseduo-types that aren't meant to survive lowering.

- An attempt to declare a variable with a tuple type expands into a tuple of declarations

- An attempt to reference such a tuple-ified variable leads to a tuple of expressions

- An attempt to extract a member from such a tuple expression will pick the appropriate sub-element

- Dereference a tuple by dereferencing the primary expression

- Expand a tuple in the argument list to a call into N arguments (by recursively flattening the tuple)

- Don't create tuple types when not generating GLSL

- Make sure to preserve the specialized type of a call expression through lowering, since emission of unchecked calls relies on that info.
  - TODO: maybe the infix/prefix/postifx/select information should come in as a side-band? Should we have modifiers on expressions?

- Make sure to offset the layout for a nested field based on teh base offset of its parent variable, when generating declarations for nested fields

1 files changed, 0 insertions, 1 deletions

diff --git a/source/slang/slang-stdlib.cpp b/source/slang/slang-stdlib.cpp
index 9d6f812cd..b3a48adea 100644
--- a/source/slang/slang-stdlib.cpp
+++ b/source/slang/slang-stdlib.cpp
@@ -1434,7 +1434,6 @@ namespace Slang
                         // When translating to GLSL, we need to break apart the `location` argument.
                         //
                         // TODO: this should realy be handled by having this member actually get lowered!
-                        int glslLoadCoordCount = kBaseTextureTypes[tt].coordCount + isArray;
                         static const char* kGLSLLoadCoordsSwizzle[] = { "", "", "x", "xy", "xyz", "xyzw" };
                         static const char* kGLSLLoadLODSwizzle[]    = { "", "", "y", "z", "w", "error" };