Start exposing a new COM-lite API (#987)

* Start exposing a new COM-lite API

This change is mostly about exposing a new API to the Slang compiler that allows more fine-grained control over the compilation flow. The basic concepts in the new API are:

* An `IGlobalSession` is the granularity at which we load/parse the Slang stdlib, and therefore gives applications a way to amortize startup cost for the library across multiple compiles. This is a concept that might be able to go away in a future version of Slang.

* An `ISession` owns all the code that gets loaded/compiled/generated. Any `import`ed modules are shared across everything in a session (we don't re-parse/-check the code when we see another `import` for the same module). Any generic- or interface-based code in the session can be specialized using types from the same session (but not necessarily across sessions).

* An `IModule` is the unit of code loading and scoping. It doesn't expose any API in this change, but would be the right scope for looking up types or entry points by name.

* An `IProgram` is a "linked" combination of modules and entry points from which code can be generated and reflection information queried.

This change re-uses the existing reflection API types, rather than introduce a new API that duplicates that functionality. That will probably change in a future revision.

There are two major pieces of functionality added here that aren't related to the new API:

* We now have an API concept of "entry point groups" which are one or more entry points that are intended to be used together so that they need to have non-overlapping parameters. For now this is being used to handle "hit groups" and local root signatures for ray tracing, but I'm not sure this is a concept we will keep in the long run.

* We have a very special-case (client-application-specific) flag that ascribes special meaning to the `shared` keyword, so that it can be attached to global parameters to indicate that they are actually to be part of the local root signature rather than the global one for DXR.

None of the API design (including naming) here is finalized; the only reason to check in the changes at this point to avoid having a long-running branch that leads to merge pain. Clients should *not* try to depend on the new API just yet, since it is still a work in progress.

* fixup: clang warning

* fixup: try to detect clang C++11 support

* fixup

* fixup

* fixup

* fixup

* fixup: review feedback

1 files changed, 12 insertions, 22 deletions

diff --git a/tests/compute/interface-shader-param3.slang b/tests/compute/interface-shader-param3.slang
index 3c8b24be1..f4f45689c 100644
--- a/tests/compute/interface-shader-param3.slang
+++ b/tests/compute/interface-shader-param3.slang
@@ -45,17 +45,19 @@ int test(
 //TEST_INPUT:ubuffer(data=[0 0 0 0], stride=4):dxbinding(0),glbinding(0),out
 RWStructuredBuffer<int> gOutputBuffer;
 
-// Note: while we declare `gStrategy` here, there is no matching
-// line providing input data at this point. That is partly to
-// work around an apparent bug in the test runner, but it is also
-// to reflect the fact that this declaration does not cause a
-// constant buffer binding to be allocated, because just from
-// the declaration of `gStrategy` we cannot tell whether a
-// constant buffer binding is even needed (there might be no
-// uniform/ordinary data).
-//
 ConstantBuffer<IRandomNumberGenerationStrategy> gStrategy;
 
+// Note: The current strategy we use for laying out shader
+// parameters in the presence of existential/interface types
+// is to always put global-scope parameters before any
+// entry-point parameters. As a result we need to provide
+// the buffer for the specialized version of `gStrategy`
+// here, and we will go ahead and provide the concrete
+// type argument at the same time.
+//
+//TEST_INPUT: globalExistentialType MyStrategy
+//TEST_INPUT:cbuffer(data=[1 0 0 0], stride=4):dxbinding(0),glbinding(1)
+
 [numthreads(4, 1, 1)]
 void computeMain(
 
@@ -81,7 +83,7 @@ void computeMain(
 //
 // Here's the incantation to make the test runner fill in the constant buffer:
 //
-//TEST_INPUT:cbuffer(data=[256 0 0 0 16 0 0 0], stride=4):dxbinding(0),glbinding(1)
+//TEST_INPUT:cbuffer(data=[256 0 0 0 16 0 0 0], stride=4):dxbinding(1),glbinding(2)
 //
 // So, the value `256` will be used for `extra` and the value `16`
 // will be written to the first four bytes of the concrete value
@@ -134,16 +136,4 @@ struct MyModifier : IModifier
     }
 }
 
-//TEST_INPUT: globalExistentialType MyStrategy
 //TEST_INPUT: entryPointExistentialType MyModifier
-
-// Once the concrete types are plugged in, the compiler can
-// see that `gStrategy` needs a constant buffer register/binding.
-// It will alocate the location for `gStrategy` after all other
-// shader parameters, to ensure that different specializations
-// of the same shader will agree on the locations for all the
-// non-interface-type parameters.
-//
-//TEST_INPUT:cbuffer(data=[1 0 0 0], stride=4):dxbinding(1),glbinding(2)
-
-