Checking if a function is a function template

[deadlocklogic]

How to check if a Function is a template?
BTW Looks like a function template in a translation unit appears in Functions and Templates properties.
Sorry for these basic questions but couldn't find any documentations about how the AST is structured.

[tritao]

BTW Looks like a function template in a translation unit appears in Functions and Templates properties.

Yes, this is how Clang AST is designed IIRC, FunctionTemplate is only a container for the specializations, and holds a reference to the templated function.

How to check if a Function is a template?

You could iterate through the function templates and compare its TemplatedFunction member to the function, but that might be slow, depending on what you're doing.

I don't think there is an easy and fast way to do this, it's never been needed before. So if you need it, we can add it. The easiest way looks like might be to add a new FunctionTemplate field to Function and just set that after a template is processed here: https://github.com/mono/CppSharp/blob/main/src/Parser/ASTConverter.cs#L1924

(_decl.TemplatedDecl as Function).FunctionTemplate = _decl;

Would something like that work for you?

[deadlocklogic]

Yes actually many extensions are needed to make things work. I don't know why such basic functionality is unavailable, doesn't the C# generator take care of class/function templates already?
My approach to generating bindings for dynamically typed languages is that almost every AST entity should be converted (especially for lua, python).
What I am doing now is refactoring my project to the best way which I can start migrating to CppSharp.
What I believe (and would be optimal for making this project easily extendable), is to abstract all the C# generator functionality and delegate it to an isolated module (with all its custom AST members, passes, options) etc ..., and focus more on a unified C++ AST parser and a generic generator.
This way each generator could have his own custom: AST members, passes, driver options etc...

[deadlocklogic]

Just from a parsing point of view from the project cppast which is based on libclang and greatly abstracts the C++ AST:
function/class templates are represented by a cpp_template class and doesn't need to have duplicated entites.
Maybe if you have little time you can checkout how this project is structured, and with a little refactoring we can achieve a more robust/versatile AST representation.

[tritao]

Yes actually many extensions are needed to make things work. I don't know why such basic functionality is unavailable, doesn't the C# generator take care of class/function templates already?

Yes, and this has never been a problem

What I believe (and would be optimal for making this project easily extendable), is to abstract all the C# generator functionality and delegate it to an isolated module (with all its custom AST members, passes, options) etc ..., and focus more on a unified C++ AST parser and a generic generator.

The parser and AST are already abstracted into their own model, and 99% of the C# generator code is already well contained into its own files. The fact we already supports multiple non .NET languages shows that what we have is extendable. We could split generators into their own DLLs, in fact we considered it in the past, but I am not convinced it would bring any value. I have seen projects go that route before only to revert things to a mono-repo world.

With that approach you wouldn't be easily able to share passes between families of generators either, which is a common thing.

Just from a parsing point of view from the project cppast which is based on libclang and greatly abstracts the C++ AST:
function/class templates are represented by a cpp_template class and doesn't need to have duplicated entites.

libclang has plenty of limitations, in fact we started with it years ago, only to change and use the original C++ Clang API. So I wouldn't take any of its design decisions has being particularly better.

In this specific case, function AST node functionality being duplicated inside template so you don't have a different node is just a different design, doesn't really matter much in practice tbh. I don't think one is particularly better than the other, and there is value in us adopting the original Clang AST structure.

If you have other ideas on how to improve the AST feel free to share. But I would say what we have is pretty versatile as we have used it as an universal AST to represent other languages, like Java (in the Embeddinator project).

[deadlocklogic]

Yes adding a property to check if a Function is a template is really helpful.

My concern is that my lua/python bindings are not that lightweight, and handle advanced concepts which of course need more abstractions.
Just a simple illustrative example, I need to let the user set custom options:
1- a filter for members which need to be omitted
2- a visitor which helps change binding names
3- many other miscellaneous options (allow generation of a CMakeLists.txt, enclosing namespace, change the name of the root binding variable) etc...
And the only way I see is using casting everywhere. A better solution would be templating the Driver class by the generator type. (as a driver is allowed a single generator instance anyway).
In the current implementation, one cannot simply create his own generator without recompiling all CppSharp from source and add more options to the enum which is a bit off, why doesn't the Driver take a Generator directly (the GeneratorKind construct contradicts abstraction by design).

For the time being I will continue refactoring my project as best as I can to get an API compatible with CppSharp.
Then the best approach IMO is to migrate to C# and refactor what needs to be refactored, and see if a PR can be adopted.
Thanks.

[deadlocklogic]

Another thing, without bloating the issue tracker, consider parsing:

template <typename T, typename std::enable_if_t<std::is_same_v<T, int>>>
inline int Foo(T foo) {
}

trying:

if (param is NonTypeTemplateParameter)
{
    Console.WriteLine(((NonTypeTemplateParameter)param).Name);
}

Gives an empty string, are expressions in template parameters parsed?

[deadlocklogic]

All I can find is DebugText which can contain comments and unresolved types.

[tritao]

Another thing, without bloating the issue tracker, consider parsing:

template <typename T, typename std::enable_if_t<std::is_same_v<T, int>>>
inline int Foo(T foo) {
}

trying:

if (param is NonTypeTemplateParameter)
{
    Console.WriteLine(((NonTypeTemplateParameter)param).Name);
}

Gives an empty string, are expressions in template parameters parsed?

Which parameter are you trying to get in that case, T or the enable_if one?

[deadlocklogic]

The SFINAE parameter enable_if.
I know such paradigms may be useless for C# binding generation, but can work in dynamic languages like lua/python/javascript bindings.
I am used to NonTypeTemplateParameter having a type which in this case can contain an unresolved type as string typename std::enable_if_t<std::is_same_v<T, int>>.

[deadlocklogic]

Even trying:

template <typename T, int val>
inline int test(T foo) {
}

How I can obtain the type of int val template parameter?

[tritao]

template <typename T, typename std::enable_if_t<std::is_same_v<T, int>>>
inline int Foo(T foo) {
}

|-FunctionTemplateDecl <line:3:1, line:5:1> line:4:12 Foo
| |-TemplateTypeParmDecl <line:3:11, col:20> col:20 referenced typename depth 0 index 0 T
| |-NonTypeTemplateParmDecl <col:23, <scratch space>:79:1> line:3:72 'typename std::enable_if_t<std::is_same_v<T, int>>':'typename enable_if<std::is_same_v<T, int>, void>::type' depth 0 index 1
| `-FunctionDecl <line:4:1, line:5:1> line:4:12 Foo 'int (T)' inline
|   |-ParmVarDecl <col:16, col:18> col:18 foo 'T'
|   `-CompoundStmt <col:23, line:5:1>

This is what the Clang AST gives me.

If you check NonTypeTemplateParameter* Parser::WalkNonTypeTemplateParameter(const clang::NonTypeTemplateParmDecl* NTTPD) in Parser.cpp we are currently doing:

    if (NTTPD->hasDefaultArgument())
        NTP->defaultArgument = WalkExpressionObsolete(NTTPD->getDefaultArgument());

So this particular template parameter still using our obsolete expression parsing code, which I think doesn't know how to deal with this. The new one should work since it's automatically generated from Clang and supports a lot more expressions/statements.

Same for int val case.

  |-NonTypeTemplateParmDecl <col:23, col:27> col:27 'int' depth 0 index 1 val
  `-FunctionDecl <line:2:1, line:3:1> line:2:12 test 'int (T)' inline
    |-ParmVarDecl <col:17, col:19> col:19 foo 'T'
    `-CompoundStmt <col:24, line:3:1

[deadlocklogic]

So will this issue be resolved in the future?
NonTypeTemplateParameter should ideally imitate a variable declaration with an optional name and a type, and an optional default value.

[tritao]

Check #1749 and see if it helps.

[deadlocklogic]

I tried this PR with a GeneratorKind.CPlusPlus because the C# generator throwed an exception at CSharpTypePrinter.cs.
Now template <int val> has a Type which is int.
But a complex expression like template <typename T, typename std::enable_if_t<!std::is_same_v<T, int>>> still returns an empty string.