Initial implementation of interface conjunctions (#1691)

The basic feature here is the ability to use the `&` operator to produce the conjunction/intersection of two interfaces. That is, you can have interfaces:

    interface IFirst { int getFirst(); }
    interface ISecond { int getSecoond(); }

and if you need a generic function where the type parameter `T` must conform to *both* of these interfaces, you express that by constraining the parameter to the intersection of the interfaces:

    void someFunction<T : IFirst & ISecond>(T value) { ... }

Without this feature, the main alternative an application would have is to define an intermediate interface, like:

    interface IBoth : IFirst, ISecond {}

Forcing users to deal with an intermediate interface creates more work for type authors (they need to remember to inherit from the right combined interface(s)), or for `extension` authors (when you add `ISecond` to a type that used to just support `IFirst`, you had better also add `IBoth`). In the worst case, a family of N related "leaf" interfaces would give rise to an exponential number of intermediate interfaces to represnt the possible combinations.

A conjunction like `IFirst & ISecond` is officially its own type, and can be used to declare a type alias:

    typealias IBoth = IFirst & ISecond;

This change only includes the first pass of work on this feature, so there are several caveats to be aware of:

* Using a conjunction as part of an inheritance clause is not yet supported (e.g., `struct X : IFirst & ISecond`). This is true even if the conjunction was introduced by an intermediate `typealias`

* The `&` syntax introduced here is only parsed in places where only a type (not an expression) is possible. This means you cannot do things like cast to a conjunction with `(IFirst & ISecond)(someValue)`.

* This work *should* apply to conjunctions of more than two interfaces (like `IA & IB & IC`) but that has not yet been tested

* In the long run it may be sensible to allow conjunctions that use concrete types, but we really ought to have the semantic checking logic rule that out for now.

* During testing, I encountered compiler crashes when trying to use this feature together with `property` declarations. Further investigation and debugging is called for.

* The handling of conjunction types is currently incomplete, in that there are many equivalences the compiler does not yet understand. For example, it is clear that `IA & IB` is equivalent to `IB & IA`, but the compiler currently does not understand this and will treat them as different types. A deeper implementation approach is called for.

* Conjunctions are currently only supported for generic type parameter constraints, when performing full specialization. Use of conjunctions for existential-type value parameters or with dynamic dispatch is not yet supported.

1 files changed, 57 insertions, 0 deletions

diff --git a/source/slang/slang-lookup.cpp b/source/slang/slang-lookup.cpp
index b54b09d63..c50364201 100644
--- a/source/slang/slang-lookup.cpp
+++ b/source/slang/slang-lookup.cpp
@@ -636,6 +636,63 @@ static void _lookUpMembersInSuperTypeImpl(
 
         _lookUpMembersInSuperType(astBuilder, name, leafType, interfaceType, leafIsInterfaceWitness, request, ioResult, inBreadcrumbs);
     }
+    else if( auto andType = as<AndType>(superType) )
+    {
+        // We have a type of the form `leftType & rightType` and we need to perform
+        // lookup in both `leftType` and `rightType`.
+        //
+        auto leftType = andType->left;
+        auto rightType = andType->right;
+
+        // Operationally, we are in a situation where we have a witness
+        // that the `leafType` we are doing lookup on is an subtype
+        // of `superType` (which is `leftType & rightType`) and now we need
+        // to construct a witness that `leafType` is a subtype of
+        // the `Left` type.
+        //
+        // Effectively, we have a witness that `T : X & Y` and we
+        // need to extract from it a witness that `T : X`.
+        // Fortunately, we have a class of subtype witness that does
+        // *precisely* this:
+        //
+        auto leafIsLeftWitness = astBuilder->create<ExtractFromConjunctionSubtypeWitness>();
+        //
+        // Our witness will be to the fact that `leafType` is a subtype of `leftType`
+        //
+        leafIsLeftWitness->sub = leafType;
+        leafIsLeftWitness->sup = leftType;
+        //
+        // The evidence for the subtype relationship will be a witness
+        // proving that `leafType : leftType & rightType`:
+        //
+        leafIsLeftWitness->conunctionWitness = leafIsSuperWitness;
+        //
+        // ... along with the index of the desired super-type in
+        // that conjunction. The index of `leftType` in `leftType & rightType`
+        // is zero.
+        //
+        leafIsLeftWitness->indexInConjunction = 0;
+
+        // The witness for the fact that `leafType : rightType` is the
+        // same as for the left case, just with a different index into
+        // the conjunction.
+        //
+        auto leafIsRightWitness = astBuilder->create<ExtractFromConjunctionSubtypeWitness>();
+        leafIsRightWitness->conunctionWitness = leafIsSuperWitness;
+        leafIsRightWitness->indexInConjunction = 1;
+        leafIsRightWitness->sub = leafType;
+        leafIsRightWitness->sup = rightType;
+
+        // We then perform lookup on both sides of the conjunction, and
+        // accumulate whatever items are found on either/both sides.
+        //
+        // For each recursive lookup, we pass the appropriate pair of
+        // the type to look up in and the witness of the subtype
+        // relationship.
+        //
+        _lookUpMembersInSuperType(astBuilder, name, leafType, leftType, leafIsLeftWitness, request, ioResult, inBreadcrumbs);
+        _lookUpMembersInSuperType(astBuilder, name, leafType, rightType, leafIsRightWitness, request, ioResult, inBreadcrumbs);
+    }
 }
 
     /// Perform lookup for `name` in the context of `type`.