Initial work on support code generation for generics with constraints (#233)

This change includes a lot of infrastructure work, but the main point is to allow code like the following:

```
// define an interface
interface Helper { float help(); }

// define a generic function that uses the interface
float test<T : Helper>( T t ) { return t.help(); }

// define a type that implements the interface
struct A : Helper { float help() { return 1.0 } }

// define an ordinary function that calls the
// generic function with a concrete type:
float doIt()
{
    A a;
    return test<A>(a);
}

```

Getting this to generate valid code involves a lot of steps. This change includes the initial version of all of these steps, but leaves a lot of gaps where more complete implementation is required.

The changes include:

- Member lookup on types has been centralized, and now handles the case where the type we are looking for a member in is a generic parameter (e.g., given `t.help()` we can now look up `help` in `Helper` by knowing that `t` is a `T` and `T` conforms to `Helper`).
  - There is an obvious cleanup still to be done here where the same exact logic should be used to look up available "constructor" declarations inside a type when the type is used like a function.

- Add a notion of subtype constraint "wittnesses" to the type system. When a generic is declared as taking `<T : Helper>` it really takes two generic parameters: the type `T` and a proof that `T` conforms to `Helper`. The actual arguments to a generic will then include both the type argument and a suitable witness argument (both type-level values).
  - As it stands right now, a witness wraps a `DeclRef` to the declaration that represents the appropriate subtype relationship. So if we have `struct A : Helper`, that `: Helper` part turns into an `InheritanceDecl` member, and a reference to that member can serve as a witness to the fact that `A` conforms to `Helper`.

- Make explicit generic application `G<A,B>` synthesize the additional arguments that represent conformances required by the generic.
  - This does *not* yet deal with the case where a generic is implicitly specialized as part of an ordinary call `G(a,b)`

- A bug fix to not auto-specialize generics during lookup. The problem here was related to an attempted fix of an earlier issue.
  During checking of a method nested in a generic type, we were running into problems where `DeclRefType::create()` was getting called on an un-specialized reference to `vector`, and this was leading to a crash when the code looked for the arguments for the generic. This was worked around by having name lookup automatically specialize any generics it runs into while going through lookup contexts.

  That choice creates the problem that in a generic method like this:

  ```
  void test<T>(T val) { ... }
  ```

  any reference to `val` inside the body of `test` will end up getting specialized so that it is effectively `test<T>::val`, when that isn't really needed.

- Add front-end logic to check that when a type claims to conform to an interface it actually must provide the methods required by the interface. The checking process goes ahead and builds a front-end "witness table" that maps declarations in the interface being conformed to over to their concrete implementations for the type.
  - At the moment the checking is completely broken and bad: it assumes that *any* member with the right name is an appropriate declaration to satisfy a requirement. That obviously needs to be fixed.

- Add an explicit operation to the IR for lookup of methods: `lookup_interface_method(w, r)` where `w` is a reference to the "witness" value and `r` is an `IRDeclRef` for the member we want to look up.

- Add an explicit notion of witness tables to the IR. These end up being the IR representation of an `InheritanceDecl` in a type, and they are generated by enumerating the members that satisfy the interface requirements (which were handily already enumerated by the front-end checking). The witness table is an explicit IR value, and so it will be referenced/used at the site where conformance is being exploited (e.g., as part of a `specialize` call), so it should be safe to eliminate witness tables that are unused (since they represent conformances that aren't actually exploited). Similarly, the entries in a witness table are uses of the functions that implement interface methods, and so keep those live.
  - In order to implement the above, I did a bit of a cleanup pass on the IR representation so that there is an `IRUser` base that `IRInst` inherits from, so that we can have users of values that aren't instructions.

- One annoying thing is that because of how types and generics are handled in the IR, we needed a way to have a type-level `Val` that wraps an IR-level value: e.g., to allow an IR-level witness table to be used as one of the arguments for specialization of a generic. The design I chose here is to have a "proxy" `Val` subclass (`IRProxyVal`) that wraps an `IRValue*`. These should only ever appear as part of types and `DeclRef`s that are used by the IR.
  - One annoying bit here is that an IR value might then have a use that is not manifest in the set of IR instructions, and instead only appears as part of a type somewhere.
  - I'm not 100% happy with this design, but it seems like we'd have to tackle similar issues if/when we eventually allow functions to have `constexpr` or `@Constant` parameters

- Make generic specialization also propagate witness table arguments through to their use sites (this is mostly just the existing substitution machinery, once we have `IRProxyVal`), and then include logic to specialize `lookup_interface_method` instructions when their first operand is a concrete witness table.

All of this work allows a single limited test using generics with constraints to pass, but more work is needed to make the solution robust.

1 files changed, 91 insertions, 2 deletions

diff --git a/source/slang/syntax.h b/source/slang/syntax.h
index f5e22d9b5..d32c4de15 100644
--- a/source/slang/syntax.h
+++ b/source/slang/syntax.h
@@ -12,6 +12,7 @@
 
 namespace Slang
 {
+    struct IRValue;
     class Name;
     class Session;
     class Substitutions;
@@ -450,6 +451,9 @@ namespace Slang
         DeclRefBase GetParent() const;
 
         int GetHashCode() const;
+
+        // Debugging:
+        String toString() const;
     };
 
     template<typename T>
@@ -787,17 +791,92 @@ namespace Slang
         //
         // We build up a list of these "breadcrumbs" while doing
         // lookup, and store them alongside each item found.
+        //
+        // As an example, suppose we have an HLSL `cbuffer` declaration:
+        //
+        //     cbuffer C { float4 f; }
+        //
+        // This is syntax sugar for a global-scope variable of
+        // type `ConstantBuffer<T>` where `T` is a `struct` containing
+        // all the members:
+        //
+        //     struct Anon0 { float4 f; };
+        //     __transparent ConstantBuffer<Anon0> anon1;
+        //
+        // The `__transparent` modifier there captures the fact that
+        // when somebody writes `f` in their code, they expect it to
+        // "see through" the `cbuffer` declaration (or the global variable,
+        // in this case) and find the member inside.
+        //
+        // But when the user writes `f` we can't just create a simple
+        // `VarExpr` that refers directly to that field, because that
+        // doesn't actually reflect the required steps in a way that
+        // code generation can use.
+        //
+        // Instead we need to construct an expression like `(*anon1).f`,
+        // where there is are two additional steps in the process:
+        //
+        // 1. We needed to dereference the pointer-like type `ConstantBuffer<Anon0>`
+        //    to get at a value of type `Anon0`
+        // 2. We needed to access a sub-field of the aggregate type `Anon0`
+        //
+        // We *could* just create these full-formed expressions during
+        // lookup, but this might mean creating a large number of
+        // AST nodes in cases where the user calls an overloaded function.
+        // At the very least we'd rather not heap-allocate in the common
+        // case where no "extra" steps need to be performed to get to
+        // the declarations.
+        //
+        // This is where "breadcrumbs" come in. A breadcrumb represents
+        // an extra "step" that must be performed to turn a declaration
+        // found by lookup into a valid expression to splice into the
+        // AST. Most of the time lookup result items don't have any
+        // breadcrumbs, so that no extra heap allocation takes place.
+        // When an item does have breadcrumbs, and it is chosen as
+        // the unique result (perhaps by overload resolution), then
+        // we can walk the list of breadcrumbs to create a full
+        // expression.
         class Breadcrumb : public RefObject
         {
         public:
             enum class Kind
             {
-                Member, // A member was references
-                Deref, // A value with pointer(-like) type was dereferenced
+                // The lookup process looked "through" an in-scope
+                // declaration to the fields inside of it, so that
+                // even if lookup started with a simple name `f`,
+                // it needs to result in a member expression `obj.f`.
+                Member,
+
+                // The lookup process took a pointer(-like) value, and then
+                // proceeded to derefence it and look at the thing(s)
+                // it points to instead, so that the final expression
+                // needs to have `(*obj)`
+                Deref,
+
+                // The lookup process saw a value `obj` of type `T` and
+                // took into account an in-scope constraint that says
+                // `T` is a subtype of some other type `U`, so that
+                // lookup was able to find a member through type `U`
+                // instead.
+                Constraint,
             };
 
+            // The kind of lookup step that was performed
             Kind kind;
+
+            // As needed, a reference to the declaration that faciliated
+            // the lookup step.
+            //
+            // For a `Member` lookup step, this is the declaration whose
+            // members were implicitly pulled into scope.
+            //
+            // For a `Constraint` lookup step, this is the `ConstraintDecl`
+            // that serves to witness the subtype relationship.
+            //
             DeclRef<Decl> declRef;
+
+            // The next implicit step that the lookup process took to
+            // arrive at a final value.
             RefPtr<Breadcrumb> next;
 
             Breadcrumb(Kind kind, DeclRef<Decl> declRef, RefPtr<Breadcrumb> next)
@@ -1060,6 +1139,16 @@ namespace Slang
         }        
     }
 
+    // TODO: where should this live?
+    RefPtr<Substitutions> createDefaultSubstitutions(
+        Session*        session,
+        Decl*           decl,
+        Substitutions*  parentSubst);
+
+    RefPtr<Substitutions> createDefaultSubstitutions(
+        Session* session,
+        Decl*   decl);
+
 } // namespace Slang
 
 #endif
\ No newline at end of file