Add basic support for entry points in `.slang-lib` files. (#1112)

* Add basic support for entry points in `.slang-lib` files.

The basic idea here is that when writing out a `.slang-lib` file based on a compile request, we include new sections in the generated RIFF that represent the entry points that were requested. The entry-point information is serialized in an entirely ad hoc fashion (a future change might clean it up to use the `OffsetContainer` machinery), and contains the name, profile, and mangled symbol name of an entry point.

When deserializing this information, we create a list of "extra" entry points that gets attached to the front-end compile requests. These "extra" entry points get turned into `EntryPoint` objects at the same place in the code that entry points specified on the command line or via API would be checked, but the extra entry points bypass the semantic checking and just create "dummy" `EntryPoint` objects.

Aside: the ability for a compile request to end up with entry points that weren't originally specified via API or command-line is not new. We already had support for compiling a translation unit with entry points entirely specified via `[shader(...)]` attributes, and this new support tries to function similarly.

Because the "dummy" entry points don't retain AST-level information, several parts of the code have been modified to defensively check for `EntryPoint` objects without a matching AST declaration, and skip over them.
The main place where this creates a problem is paramete binding, where ignoring the dummy entry point is appropriate since we currently assume linked-in library code has been laid out manually.

One small cleanup here is that the `-r` command-line flag and the `spAddLibraryReference` API functio now bottleneck through a common routine to do their work, so that they both gain the new behavior without needing copy-paste programming.

In order to keep the existing test case for library linking with entry points working, I had to add a flag to the `render-test` tool so that it can skip specifying entry point names as part of the compile request it creates. In that case it must instead assume that the entry points will be added to the compile request via other means. This logic is a bit magical, and hints that we should be looking for other ways to expose the library linking functionality over time.

* fixup: remove alignment assertion

1 files changed, 13 insertions, 0 deletions

diff --git a/source/core/slang-riff.cpp b/source/core/slang-riff.cpp
index 2e633f2e7..1de51d840 100644
--- a/source/core/slang-riff.cpp
+++ b/source/core/slang-riff.cpp
@@ -548,6 +548,19 @@ void RiffContainer::ListChunk::findContained(FourCC type, List<ListChunk*>& out)
     }
 }
 
+void RiffContainer::ListChunk::findContained(FourCC type, List<DataChunk*>& out)
+{
+    Chunk* chunk = m_containedChunks;
+    while (chunk)
+    {
+        if (chunk->m_fourCC == type && chunk->m_kind == Chunk::Kind::Data)
+        {
+            out.add(static_cast<DataChunk*>(chunk));
+        }
+        chunk = chunk->m_next;
+    }
+}
+
 RiffContainer::Data* RiffContainer::ListChunk::findContainedData(FourCC type) const
 {
     Chunk* found = findContained(type);