Fix Enum Constructor Specialization in Generic Types

[gtong-nv]

Fix Enum Constructor Specialization in Generic Types

This PR fixes an issue where synthesized constructors for enums nested within generic types were failing to specialize correctly.

The Problem

When slang synthesizes a requirement witness (like a constructor) for an enum, it creates a new function declaration (synFunc) and adds it to the AST. The original code was creating a DirectDeclRef to this new function:

RequirementWitness(m_astBuilder->getDirectDeclRef(synFunc))

A DirectDeclRef represents a reference to a declaration without any context. It effectively treats the function as if it exists globally or independently.

This becomes a problem when the enum is nested within a generic type (e.g., struct Test<T> { enum Inner { ... } }). The constructor for Inner inherently depends on the generic parameters of its parent (e.g., T). When the compiler later attempts to specialize Test<int>, it encounters the DirectDeclRef. Because this reference has no base or parent pointer, the compiler cannot trace it back to the generic Test<T>, and thus has no way to substitute int for T. This results in an invalid reference to an unspecialized generic constructor within a specialized type context, leading to verification failures or incorrect IR.

The Fix

The fix is to construct the witness using a MemberDeclRef that is rooted at the parent declaration:

RequirementWitness(
    m_astBuilder->getMemberDeclRef(getDefaultDeclRef(context->parentDecl), synFunc))

1. getDefaultDeclRef(context->parentDecl) retrieves the correct reference to the parent enum (which correctly links back to the generic struct).
2. getMemberDeclRef creates a reference to synFunc relative to that parent.

This constructs a proper chain of references: Constructor -> Enum -> Generic Struct. When the compiler specializes Test<int>, it can now traverse this chain, identify that the constructor is part of a generic instantiation, and correctly apply substitutions to produce the specialized constructor for Test<int>.Inner.

This PR also adds a few nullptr checks and removes the duplicated findWitnessVal with findWitnessTableEntry.

Fixes: #8887

[tangent-vector]

This looks great. Thank you again for digging down (well, up in terms of the compiler's dataflow) to the root cause of the problem.

I would like to hear your response to the two questions I raised about the code, but I don't know if either of those can/should turn into an actual code change.

[tangent-vector]

Do we think this conditional is still good/necessary?

Unless we have a reason to believe that innerInst could be null for valid input code, I would rather see a SLANG_ASSERT(innerInst) than an if(innerInst). Either way, this code seems unrelated to the actual fix.

[gtong-nv]

Looks like we still need to keep this conditional check.
As the innerInst = findInnerMostGenericReturnVal(genInst); could return nullptr for the generic that doesn't have return val ( enum in this case?)

The genInst causing the trouble has only a basic block contains a T Op_Param.
We would have to keep check, unless this inst should not be here in the first place..

[gtong-nv]

Thanks for the feedback! Sorry for the late response. I have addressed the comment and update the way we generate memberDeclRef.

[gtong-nv]

Looks like we still need to keep this conditional check.
As the innerInst = findInnerMostGenericReturnVal(genInst); could return nullptr for the generic that doesn't have return val ( enum in this case?)

The genInst causing the trouble has only a basic block contains a T Op_Param.
We would have to keep check, unless this inst should not be here in the first place..