libclang is giving different type spelling starting from clang 15.0.0

[mosvard]

After updating Clang from version 14 to 15, I noticed a change in the behavior of the clang_getTypeSpelling(CXType CT) function. Previously, the function used to return the full type name, including the namespace. However, after the update, it now returns the type name without the namespace. Perhaps there is a flag or some other setting that we can use to achieve the same behavior as we had in Clang 14. We need to obtain the full type name, including the namespace. Please suggest what we can do to address this issue.

Here is an example of my class.

#include <string>

namespace cppbind::example {
class Task {
public:
    Task(){};
    Task(const std::string& title) : _title(title) {};

    std::string& title() {
        return _title;
    };

    void setTitle(const std::string& title) {
        _title = title;
    };

    bool equals(Task* t) const {
        return this == t;
    }

protected:
    std::string _title;
};
}

For example, before the update, the equals method's argument type spelling was cppbind::example::Task * but now it is Task *.

[diseraluca]

This is probably a duplicate of #61810 and #58040.

Albeit the issue should appear from 16.0 onward while 15.X should be stable with regards to 14.X, at least in our experience.

[mosvard]

Thank you for your reply, @diseraluca. I have already checked the issues you mentioned. It is suggested to use the clang::TypeName::getFullyQualifiedName function to obtain our desired result. We are using the libclang Python API in our project. Do you know how we can use this function within libclang?

[diseraluca]

I don't think that libclang exposes anything equivalent to that.

You might consider making a patch to libclang to expose it (this is what I've been doing for similar issues in my company) but that won't really help you as you will not get it before 18.X.

What I've been doing to avoid this waiting issues is to extract the declaration from a CXCursor and lower to the C++ API, so we don't need to wait for my patches to be merged+having to change release to access certain things.

I don't think that would be possible from the python API tough.

No direct solution comes to my mind, but if I was in your situation at work I would keep a company patched LLVM fork and distribute it, if needed, with your project. Pushing everything you change that is meaningful upstream to later converge back to the official LLVM.

Nonetheless, I'm not officially working on LLVM, just someone having a similar problem at his job, so you might want to try and ask some of the maintainers.

Albeit an issue on github might not be the best channel for this kind of conversation and I would suggest looking at some other possible channel of communications such as, possibly, https://discourse.llvm.org/c/beginners/17.

[mosvard]

Thanks, @diseraluca, for sharing your knowledge!