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, 53 insertions, 7 deletions

diff --git a/source/slang/slang-parser.cpp b/source/slang/slang-parser.cpp
index 12fa90480..b15d215da 100644
--- a/source/slang/slang-parser.cpp
+++ b/source/slang/slang-parser.cpp
@@ -4066,21 +4066,67 @@ namespace Slang
         return parameter;
     }
 
-    Expr* Parser::ParseType()
+        /// Parse an "atomic" type expression.
+        ///
+        /// An atomic type expression is a type specifier followed by an optional
+        /// body in the case of a `struct`, `enum`, etc.
+        ///
+    static Expr* _parseAtomicTypeExpr(Parser* parser)
     {
-        auto typeSpec = parseTypeSpec(this);
+        auto typeSpec = parseTypeSpec(parser);
         if( typeSpec.decl )
         {
-            AddMember(currentScope, typeSpec.decl);
+            AddMember(parser->currentScope, typeSpec.decl);
         }
-        auto typeExpr = typeSpec.expr;
-
-        typeExpr = parsePostfixTypeSuffix(this, typeExpr);
+        return typeSpec.expr;
+    }
 
-        return typeExpr;
+        /// Parse a postfix type expression.
+        ///
+        /// A postfix type expression is an atomic type expression followed
+        /// by zero or more postifx suffixes like array brackets.
+        ///
+    static Expr* _parsePostfixTypeExpr(Parser* parser)
+    {
+        auto typeExpr = _parseAtomicTypeExpr(parser);
+        return parsePostfixTypeSuffix(parser, typeExpr);
     }
 
+        /// Parse an infix type expression.
+        ///
+        /// Currently, the only infix type expression we support is the `&`
+        /// operator for forming interface conjunctions.
+        ///
+    static Expr* _parseInfixTypeExpr(Parser* parser)
+    {
+        auto leftExpr = _parsePostfixTypeExpr(parser);
+
+        for(;;)
+        {
+            // As long as the next token is an `&`, we will try
+            // to gobble up another type expression and form
+            // a conjunction type expression.
+
+            auto loc = peekToken(parser).loc;
+            if(!AdvanceIf(parser, TokenType::OpBitAnd))
+                break;
+
+            auto rightExpr = _parsePostfixTypeExpr(parser);
+
+            auto andExpr = parser->astBuilder->create<AndTypeExpr>();
+            andExpr->loc = loc;
+            andExpr->left = TypeExp(leftExpr);
+            andExpr->right = TypeExp(rightExpr);
+            leftExpr = andExpr;
+        }
+
+        return leftExpr;
+    }
 
+    Expr* Parser::ParseType()
+    {
+        return _parseInfixTypeExpr(this);
+    }
 
     TypeExp Parser::ParseTypeExp()
     {