Closed AutonomicPerfectionist closed 1 year ago
AFAIK, the CMake method maps multiple symbols to underscores, in turn we'll have problems restoring the symbol. Do we ever try to demangle symbols? If not, then letting the *
become _
is probably fine. Otherwise, we may need to do our own pre-processing step and map _
to say _cpp_star_cpp_
or something.
Looking at your changes, answers my question. The implicitly_convertible
function is operating on the mangled name, so we should take care to make sure the _
came from *
and not say +
.
I managed to find where the parameter types were mutated and fixed them, so now we no longer have to allow the underscore as a pointer specifier. What I did was decouple the signature information from the mangled function name so that the function can still be called while the signature can contain special characters. The only processing done on the parameter types before it reaches cpp_is_callable()
should be just making them lowercase. We should probably stick a cpp_assert_type()
call somewhere in the method creation process to prevent invalid types from sneaking in though, as I couldn't find such a call anywhere along the chain.
🚀 [bumpr] Bumped! New version:v0.0.8 Changes:v0.0.7...v0.0.8
Is this pull request associated with an issue(s)? Fixes #106
Description
This PR implements the first fix discussed in #106, which adds the underscore as a way to specify a pointer. This is more of a simple hack to fix the issue with pointer types in method signatures.If a different fix is desired, this PR will be altered instead of closed since it also adds tests for pointer signatures in general.This PR now fixes a type mutation done in the method creation and calling process, such that methods can now have pointer types in the signatures.
TODOs