Fix an issue with explicit enum tag types (shader-slang#1495)

The basic problem here was that in a declaration like:

```hlsl
enum Color : uint { Red, Orange, ... }
```

The `: uint` bit is represented as an `InheritanceDecl`, because that is what we use to represent the syntactic form of inheritance clauses like that. At the point where we parse the `InheritanceDecl` we don't yet know whether it represents a base interface or a "tag type" like `uint` in this case.

The root problem that is then created is: an `enum` type is *not* a subtype of its "tag type," and treating it like a subtype can create problems.

The main problem that arises is that looking in a type like `Color` will find both the members of color *and* the members of `uint`. In the case of things like `__init` declarations, that creates a problem where the `Color` type has two different `__init`s that take a `uint`:

* The one it inherits from `uint` via that `InheritanceDecl` (even though it shouldn't)
* The one it gets via an extension just for conforming to `__EnumType` (a non-user-exposed `interface` in the standard library)

Because both of those `__init`s are inherited, neither is preferred over the other one and they create an ambiguity if somebody tries to write:

```hlsl
uint u = ...;
Colorc = Color(u);
```

The solution used in this PR is to add a compiler-internal modifier to the `InheritanceDecl` that introduces a "tag type" to an `enum`, in an early phase of checking (one of the ones that occurs before it is legal to enumerate the bases of a type). Then the lookup process is modified to ignore `InheritanceDecl`s with that modifier when doing lookup in super-types (since the declaration does *not* indicate a subtype/supertype relationship).

This appears to get the basic feature working again, although it is possible that there are other parts of the compiler that use `InheritanceDecl`s and mistakently assume that all `InheritanceDecl`s introduce subtype/supertype relationships. We probably need to do a significant audit of the code to start being more clear about the nature of the relationships such declarations introduce. Such steps are left to future changes.

Co-authored-by: Yong He <yonghe@outlook.com>

Author: Tim Foley

source/slang/slang-ast-modifier.h

@@ -29,6 +29,9 @@ class ExportedModifier : public Modifier { SLANG_CLASS(ExportedModifier)};
 class ConstExprModifier : public Modifier { SLANG_CLASS(ConstExprModifier)};
 class GloballyCoherentModifier : public Modifier { SLANG_CLASS(GloballyCoherentModifier)};
 
+    /// A modifier that indicates an `InheritanceDecl` should be ignored during name lookup (and related checks).
+class IgnoreForLookupModifier : public Modifier { SLANG_CLASS(IgnoreForLookupModifier) };
+
 // A modifier that marks something as an operation that
 // has a one-to-one translation to the IR, and thus
 // has no direct definition in the high-level language.

source/slang/slang-check-decl.cpp

@@ -2985,6 +2985,16 @@ namespace Slang
             // For now we will just be harsh and require it
             // to be one of a few builtin types.
             validateEnumTagType(tagType, tagTypeInheritanceDecl->loc);
+
+            // Note: The `InheritanceDecl` that introduces a tag
+            // type isn't actually representing a super-type of
+            // the `enum`, and things like name lookup need to
+            // know to ignore that "inheritance" relationship.
+            //
+            // We add a modifier to the `InheritanceDecl` to ensure
+            // that it can be detected and ignored by such steps.
+            //
+            addModifier(tagTypeInheritanceDecl, m_astBuilder->create<IgnoreForLookupModifier>());
         }
         decl->tagType = tagType;
 

source/slang/slang-lookup.cpp

@@ -528,6 +528,14 @@ static void _lookUpMembersInSuperTypeDeclImpl(
             {
                 ensureDecl(semantics, inheritanceDeclRef.getDecl(), DeclCheckState::CanUseBaseOfInheritanceDecl);
 
+                // Some things that are syntactically `InheritanceDecl`s don't actually
+                // represent a subtype/supertype relationship, and thus we shouldn't
+                // include members from the base type when doing lookup in the
+                // derived type.
+                //
+                if(inheritanceDeclRef.getDecl()->hasModifier<IgnoreForLookupModifier>())
+                    continue;
+
                 auto baseType = getSup(astBuilder, inheritanceDeclRef);
                 if( auto baseDeclRefType = as<DeclRefType>(baseType) )
                 {

tests/language-feature/enums/explicit-tag-type.slang

@@ -0,0 +1,33 @@
+// explicit-tag-type.slang
+
+// Test that the underlying "tag type" of an `enum` can be set.
+
+//TEST(compute):COMPARE_COMPUTE:
+
+enum Channel : uint
+{
+    Red,
+    Green,
+    Blue,
+    Alpha,
+}
+
+uint test(uint val)
+{
+    Channel channel = Channel(val);
+    uint u = uint(channel) + 1;
+    channel = Channel(u & 0x3);
+    return uint(channel);
+}
+
+//TEST_INPUT:ubuffer(data=[0 0 0 0], stride=4):out,name=outputBuffer
+RWStructuredBuffer<uint> outputBuffer;
+
+[numthreads(4, 1, 1)]
+void computeMain(uint3 dispatchThreadID : SV_DispatchThreadID)
+{
+    uint tid = dispatchThreadID.x;
+    uint inVal = tid;
+    uint outVal = test(inVal);
+    outputBuffer[tid] = outVal;
+}

tests/language-feature/enums/explicit-tag-type.slang.expected.txt

@@ -0,0 +1,4 @@
+1
+2
+3
+0