Skip to content

Desugar template type alias specialisations in wrapper return types#997

Open
guitargeek wants to merge 1 commit into
compiler-research:mainfrom
guitargeek:cppyy-218
Open

Desugar template type alias specialisations in wrapper return types#997
guitargeek wants to merge 1 commit into
compiler-research:mainfrom
guitargeek:cppyy-218

Conversation

@guitargeek
Copy link
Copy Markdown

When generating a JitCall wrapper for a function whose return type is a template type alias specialisation -- e.g.
std::enable_if_t<is_constructible_v<...>, std::any> as on std::make_any -- get_type_as_string left the alias sugared. The printer's FullyQualifiedName policy applies to types but does not propagate into expression-level non-type template arguments, so identifiers like is_constructible_v were emitted without their std:: qualifier and the wrapper failed to compile with use of undeclared identifier.

Strip TemplateSpecializationType sugar where isTypeAlias() is true before printing. The desugared form is the alias body with explicit arguments substituted (here, std::any), which compiles cleanly. Regular typedefs (std::string and friends) are not TemplateSpecializationType sugar and keep their preferred name.

Reported as cppyy issue
compiler-research/cppyy#218; reproducer is cppyy.gbl.std.make_any["MyClass*", "MyClass*"](my_inst) after cppyy.include("any"). Adds a regression test that instantiates std::make_any<MyClass*, MyClass*> and asserts MakeFunctionCallable returns a kGenericCall JitCall.

Description

Please include a summary of changes, motivation and context for this PR.

Fixes # (issue)

Type of change

Please tick all options which are relevant.

  • Bug fix
  • New feature
  • Requires documentation updates

Testing

Please describe the test(s) that you added and ran to verify your changes.

Checklist

  • I have read the contribution guide recently

@codecov
Copy link
Copy Markdown

codecov Bot commented May 12, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.79%. Comparing base (1ea28e2) to head (b6147ef).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #997      +/-   ##
==========================================
+ Coverage   82.78%   82.79%   +0.01%     
==========================================
  Files          15       15              
  Lines        5048     5052       +4     
==========================================
+ Hits         4179     4183       +4     
  Misses        869      869              
Files with missing lines Coverage Δ
lib/CppInterOp/CppInterOp.cpp 88.97% <100.00%> (+0.01%) ⬆️
Files with missing lines Coverage Δ
lib/CppInterOp/CppInterOp.cpp 88.97% <100.00%> (+0.01%) ⬆️
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

When generating a JitCall wrapper for a function whose return type is a
template type alias specialisation -- e.g.
`std::enable_if_t<is_constructible_v<...>, std::any>` as on
`std::make_any` -- get_type_as_string left the alias sugared. The
printer's FullyQualifiedName policy applies to types but does not
propagate into expression-level non-type template arguments, so
identifiers like `is_constructible_v` were emitted without their `std::`
qualifier and the wrapper failed to compile with `use of undeclared
identifier`.

Strip TemplateSpecializationType sugar where isTypeAlias() is true
before printing. The desugared form is the alias body with explicit
arguments substituted (here, std::any), which compiles cleanly. Regular
typedefs (std::string and friends) are not TemplateSpecializationType
sugar and keep their preferred name.

Reported as cppyy issue
compiler-research/cppyy#218; reproducer is
`cppyy.gbl.std.make_any["MyClass*", "MyClass*"](my_inst)` after
`cppyy.include("any")`. Adds a regression test that instantiates
std::make_any<MyClass*, MyClass*> and asserts MakeFunctionCallable
returns a kGenericCall JitCall.
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.

1 participant