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

Mangled names #34

Open
rokups opened this issue Feb 3, 2018 · 7 comments
Open

Mangled names #34

rokups opened this issue Feb 3, 2018 · 7 comments
Labels

Comments

@rokups
Copy link
Contributor

rokups commented Feb 3, 2018

Would it be possible to expose mangled names? It could be very helpful when generating API wrappers for foreign languages.

@foonathan
Copy link
Collaborator

I see what I can do about it.

@Manu343726
Copy link
Contributor

I would be very careful with this. While libclang exposes mangled entity names, these names are specific to the clang compiler (Actually, clang on linux implements itanium iirc). Also nothing prevents LLVM to change the symbol mangling scheme between versions, so you're not guaranteed that your cppast running say libclang 3.8 would work with your lib compiled with 4.0 for example.

@rokups
Copy link
Contributor Author

rokups commented Mar 4, 2018

CppSharp project successfully uses mangled names from llvm/clang though.

@Manu343726
Copy link
Contributor

Oh, I see they explicitly support Itanium and MS ABIs, interesting. Thanks for pointing out, I'm curious how they're handling the MSVC case.

@rokups
Copy link
Contributor Author

rokups commented Mar 4, 2018

Clang does support msvc ABI. https://clang.llvm.org/docs/MSVCCompatibility.html

@KevinW1998
Copy link

I am also highly interested in mangled names. Libclang directly supports it https://clang.llvm.org/doxygen/group__CINDEX__MANGLE.html and selects the right mangling depending on the platform.

@foonathan
Copy link
Collaborator

Okay, I'll add it.

Because I don't have access to the CXCursor (and can't, by design), I'd probably have to add a std::string to cpp_entity, bloating everything again.

I could also store it in the cpp_entity_index but then there's some runtime overhead on access.

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

No branches or pull requests

4 participants