Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeConformance with generics does not work #4749

Closed
fknfilewalker opened this issue Jul 27, 2024 · 9 comments · Fixed by #4761 or #4839
Closed

TypeConformance with generics does not work #4749

fknfilewalker opened this issue Jul 27, 2024 · 9 comments · Fixed by #4761 or #4839
Assignees
Labels
goal:client support Feature or fix needed for a current slang user.

Comments

@fknfilewalker
Copy link
Contributor

fknfilewalker commented Jul 27, 2024

So when having an interface which is templated, it is possible now to correctly set the type conformance with strings of the interface and implementation struct + the implementing generic type "TestInterface<float>" "TestInterfaceImpl<float>". Sadly this still results in an

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.
error

Shortened code:

public interface TestInterface<Real> {
    Real sample();
}

struct TestInterfaceImpl<Real> : TestInterface<Real> {
    Real sample() {
        return x;
    }
    Real x;
}

StructuredBuffer<TestInterface<float>> data;
@csyonghe csyonghe self-assigned this Jul 30, 2024
@csyonghe csyonghe added the goal:client support Feature or fix needed for a current slang user. label Jul 30, 2024
@csyonghe csyonghe added this to the Q3 2024 (Summer) milestone Jul 30, 2024
@fknfilewalker
Copy link
Contributor Author

fknfilewalker commented Aug 7, 2024

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
Copy link
Collaborator

csyonghe commented Aug 8, 2024

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

@peterkain
Copy link

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
Copy link
Collaborator

csyonghe commented Aug 8, 2024

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
Copy link
Collaborator

csyonghe commented Aug 8, 2024

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
Copy link
Contributor Author

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
Copy link
Collaborator

csyonghe commented Aug 8, 2024

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
Copy link
Contributor Author

@csyonghe csyonghe reopened this Aug 9, 2024
@saipraveenb25 saipraveenb25 self-assigned this Aug 12, 2024
@saipraveenb25
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
goal:client support Feature or fix needed for a current slang user.
Projects
None yet
4 participants