Skip to content

Fix incorrect template argument kind - #578

Merged
tannergooding merged 2 commits into
dotnet:mainfrom
MrJul:fix/template-argument-kind
Apr 4, 2025
Merged

Fix incorrect template argument kind#578
tannergooding merged 2 commits into
dotnet:mainfrom
MrJul:fix/template-argument-kind

Conversation

@MrJul

@MrJul MrJul commented Nov 11, 2024

Copy link
Copy Markdown
Contributor

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

@tannergooding tannergooding left a comment

Copy link
Copy Markdown
Member

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

MrJul commented Nov 18, 2024

Copy link
Copy Markdown
Contributor Author

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
Copy Markdown
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

MrJul commented Nov 20, 2024

Copy link
Copy Markdown
Contributor Author

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

@tannergooding
tannergooding merged commit af2a428 into dotnet:main Apr 4, 2025
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