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, 93 insertions, 0 deletions

diff --git a/source/slang/slang-ast-type.cpp b/source/slang/slang-ast-type.cpp
index 9c00c13ba..79df8e48b 100644
--- a/source/slang/slang-ast-type.cpp
+++ b/source/slang/slang-ast-type.cpp
@@ -938,5 +938,98 @@ Val* ThisType::_substituteImplOverride(ASTBuilder* astBuilder, SubstitutionSet s
     return substType;
 }
 
+// !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! AndType !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+
+String AndType::_toStringOverride()
+{
+    String result;
+    result.append(left->toString());
+    result.append(" & ");
+    result.append(right->toString());
+    return result;
+}
+
+bool AndType::_equalsImplOverride(Type * type)
+{
+    auto other = as<AndType>(type);
+    if (!other)
+        return false;
+
+    if(!left->equals(other->left))
+        return false;
+    if(!right->equals(other->right))
+        return false;
+
+    return true;
+}
+
+HashCode AndType::_getHashCodeOverride()
+{
+    Hasher hasher;
+    hasher.hashObject(left);
+    hasher.hashObject(right);
+    return hasher.getResult();
+}
+
+Type* AndType::_createCanonicalTypeOverride()
+{
+    AndType* canType = m_astBuilder->create<AndType>();
+
+    // TODO: proper canonicalization of an `&` type relies on
+    // several different things:
+    //
+    // * We need to re-associate types that might involve
+    //   nesting of `&`, such as `(A & B) & (C & D)`, into
+    //   a canonical form where the nesting is consistent
+    //   (i.e., always left- or right-associative).
+    //
+    // * We need to commute types so that they are in a
+    //   consistent order, so that `A & B` and `B & A` both
+    //   result in the same canonicalization. This requirement
+    //   implies that we must invent a total order on types.
+    //
+    // * We need to canonicalize `&` types where one of the
+    //   elements might be implied by another. E.g., if we
+    //   have `interface IDerived : IBase`, then a type like
+    //   `IDerived & IBase` is equivalent to just `IDerived`
+    //   because the presence of an `IBase` conformance is
+    //   implied. A special case of the above is the possibility
+    //   of duplicates in the list of types (e.g., `A & B & A`).
+    //
+    // * The previous requirement raises the problem that
+    //   the relationships between `interface`s might either
+    //   evolve over time, or be subject to `extension`
+    //   declarations in other modules. The canonicalization
+    //   algorithm must be clear about what information it
+    //   is allowed to make use of, as this can/will affect
+    //   binary interfaces (via mangled names).
+    //
+    // We are going to completely ignore these issues for
+    // right now, in the name of getting something up and running.
+    //
+    canType->left = left->getCanonicalType();
+    canType->right = right->getCanonicalType();
+
+    return canType;
+}
+
+Val* AndType::_substituteImplOverride(ASTBuilder* astBuilder, SubstitutionSet subst, int* ioDiff)
+{
+    int diff = 0;
+
+    auto substLeft  = as<Type>(left ->substituteImpl(astBuilder, subst, &diff));
+    auto substRight = as<Type>(right->substituteImpl(astBuilder, subst, &diff));
+
+    if(!diff)
+        return this;
+
+    (*ioDiff)++;
+
+    AndType* substType = m_astBuilder->create<AndType>();
+    substType->left = substLeft;
+    substType->right = substRight;
+    return substType;
+}
+
 
 } // namespace Slang