TypeConformance with generics does not work

[fknfilewalker]

TypeConformance with generics does not work

[fknfilewalker]

It seems like that this still does not work. The compiler does not crash anymore but the compilation errors out with the following message.

error 50100: No type conformances are found for interface 'TestInterface'. Code generation for current target requires at least one implementation type present in the linkage. outputBuffer[0] = data[0].sample();

I used "TestInterface<float>" and "TestInterfaceImpl<float>" for type conformance.

[csyonghe]

Did you add a ITypeConformance to your CompositeComponentType that represents your program. If not, this is an expected behavior.

[peterkain]

Hi, I'm a collaborator of the author, the following code describes how we add the type conformance to the program:

slang::ProgramLayout* layout = _p->_tempProgram->getLayout();
slang::TypeReflection* t = layout->findTypeByName(type.data());
slang::TypeReflection* c = layout->findTypeByName(conformance.data());

slang::ITypeConformance* t_c;
const SlangResult result = _p->_session->createTypeConformanceComponentType(
    c,
    t,
    &t_c,
    id_override,
    _p->_diagnosticsBlob.writeRef());
checkError(_p->_diagnosticsBlob);
if (SLANG_FAILED(result)) throw std::runtime_error("slang: type conformance error");

Basically we get the type reflections of the base type and implementing type by name. Then we create the ITypeConformance using the type reflections, which is then later added to a vector with IComponentType values for program composition, like so:

_p->_programComponents.insert(_p->_programComponents.end(), _p->_typeConformances.begin(), _p->_typeConformances.end());

const SlangResult result = _p->_session->createCompositeComponentType(
    _p->_programComponents.data(),
    _p->_programComponents.size(),
    _p->_composedProgram.writeRef(),
    _p->_diagnosticsBlob.writeRef());
checkError(_p->_diagnosticsBlob);
if (SLANG_FAILED(result)) throw std::runtime_error("slang: composition error");

The diagnosticBlob checks and SLANG_FAILED checks all seem to not detect any issue, and the values of the TypeReflections and ITypeConformance also seem to be valid in the debugger. I can also confirm that the ITypeConformance t_c is indeed in the _programComponents vector.

[csyonghe]

One thing I want to make sure is that there aren't mixed uses of modules and #includes.
When using both import and #include, there maybe duplicate entities of the same type that is seen to the compiler as different things.

[csyonghe]

I will need to understand more on what is the difference between your use case, and the test case here: tests/language-feature/interfaces/generic-interface-conformance.slang

[fknfilewalker]

Strange, the exact example you linked above also does not work. Without the generic it does though. When I set the generic TypeConformance I do it with "ITestInterface<float>" and "TestInterfaceImpl<float>".

We call createCompositeComponentType with the Program + the TypeConformance

[csyonghe]

this line
//TEST_INPUT: type_conformance TestInterfaceImpl:ITestInterface = 3

In the test file does the exactly that, so I am not sure why it works in the test but not in your application. Would it be possible for you to share a standalone cpp program that reproduces this?

[fknfilewalker]

You can find it in here
https://github.com/fknfilewalker/dyslang/tree/main/tests/slang_interface_type_conformance

using some small abstractions for slang:
https://github.com/fknfilewalker/dyslang/blob/main/include/dyslang/slangc.h
https://github.com/fknfilewalker/dyslang/blob/main/src/slangc.cpp

Note: Only tried to compile it on windows

[saipraveenb25]

I'm able to reproduce this.. looks like a bug with witness table specialization being skipped because the inst has no uses until later in the generics lowering process. This didn't happen with the test case because the TEST_INPUT line that initializes the data buffer also causes the slang-test framework to explicitly set the conformance via IComponentType::specialize. Removing that line triggers the same issue for the test case.

I think it should be a quick fix. Will open a PR asap.