Fix support for nested generic intrinsics (#1462)

The logic that detects intrinsic functions during emit was not able to properly detect an intrinsic generic method nested in a generic type. The basic problem was that this led to a `specialize(specialize(...), ...)` in the IR, which wasn't being handled (only one level of `specialize` was handled). The fix is local and simple.

The larger issue was that the author of this commit had thought our IR ruled out nested generics like this, when in fact that is precisely how we handle nested generics throughout the IR. This oversight/misunderstanding means that we might have broken passes in other places that assume nested generics cannot happen. This change doesn't pretend to fix that other issue, but we should pay attention to it.

1 files changed, 11 insertions, 0 deletions

diff --git a/source/slang/slang-emit-c-like.cpp b/source/slang/slang-emit-c-like.cpp
index a3b11a908..ce3dc8957 100644
--- a/source/slang/slang-emit-c-like.cpp
+++ b/source/slang/slang-emit-c-like.cpp
@@ -3206,6 +3206,17 @@ void CLikeSourceEmitter::emitParamTypeImpl(IRType* type, String const& name)
 IRInst* CLikeSourceEmitter::getSpecializedValue(IRSpecialize* specInst)
 {
     auto base = specInst->getBase();
+
+    // It is possible to have a `specialize(...)` where the first
+    // operand is also a `specialize(...)`, so that we need to
+    // look at what declaration is being specialized at the inner
+    // step to find the one being specialized at the outer step.
+    //
+    while(auto baseSpecialize = as<IRSpecialize>(base))
+    {
+        base = getSpecializedValue(baseSpecialize);
+    }
+
     auto baseGeneric = as<IRGeneric>(base);
     if (!baseGeneric)
         return base;