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

Fix incorrect template argument kind #578

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

MrJul
Copy link

@MrJul MrJul commented Nov 11, 2024

This PR fixes wrong template argument kinds being returned from MakeCXTemplateArgument().

It turns out that TemplateArgument::ArgKind and CXTemplateArgumentKind have different values, with StructuralValue present in the former but not the latter.

LLVM maps this explicitly: https://github.com/llvm/llvm-project/blob/00a1f1ab71302d190f8059d86a53ec62485fbce9/clang/tools/libclang/CXCursor.cpp#L1474-L1506. This PR now does the same.

I've found this issue while trying to read elements from a parameter pack (std::tuple). TemplateArgument::Pack in this case was mapped directly to CXTemplateArgumentKind::Invalid, making it impossible to retrieve the underlying elements.

A unit test has been added for this case.

tannergooding
tannergooding previously approved these changes Nov 18, 2024
Copy link
Member

@tannergooding tannergooding left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good fix, but ideally we'd allow the devs a way to get TemplateArgument::StructuralValue returned as well.

There's many "gaps" like this that I've had to polyfill for libClang, often by defining some new enum and APIs for querying the information.

@MrJul
Copy link
Author

MrJul commented Nov 18, 2024

This is a good fix, but ideally we'd allow the devs a way to get TemplateArgument::StructuralValue returned as well.

Indeed, I didn't want to add new enum to avoid breaking changes.

The new test is failing on CI because CLangSharp.Interop directly relies on the existing libClang/libClangSharp NuGet packages, which obviously don't contain the new changes yet. While testing the changes for this PR, I was a bit surprised that there wasn't a way to target a locally built library without changing the csproj.

@tannergooding
Copy link
Member

While testing the changes for this PR, I was a bit surprised that there wasn't a way to target a locally built library without changing the csproj.

The general issue is that building libClangSharp requires first having built libClang (there's complexity here due to the binary breaking changes libClang makes almost every release) and its quite expensive. Far more than is "reasonable" to handle on the free CI machines.

There's potentially some caching or similar that could be done, but the download would still be fairly large/expensive and its not something I've had time to investigate yet.


I do need to update libClangSharp anyways, for the latest release of Clang, so it should be fine to just disable the test temporarily and I'll get it handled in about a week or two.

@MrJul
Copy link
Author

MrJul commented Nov 20, 2024

I've added [Ignore] to the test for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants