compiler-research / cpycppyy Goto Github PK

The converter/executor logic has string-based tables which are used to dispatch based on the type. We should use the underlying opaque type pointer to improve efficiency, etc. This was part of what the review in PR #15 suggests as well.

I don't think so. :) And there seems to be a real benefit there to prevent crashes.

struct ScopeCursor {
    void* fDecl;
};

Certain operations that can be performed on Decls and other on Types. We have interface GetScopeFromType and GetTypeFromScope if we need to convert but I'd prefer to have these explicit. This is more aligned to the underlying compiler API. I'd be happy if we had a special opaque entity for both. Eg:

    typedef ScopeCursor* CppScope_t;

    struct TypeCursor {
        void* fType;
        operator CppScope_t() { return GetScopeFromType(*this); }
    };

    typedef TypeCursor* CppType_t;

Here the compiler could enforce some checks if we try to call an interface with the unexpected parameter. We should look into better ways to strong typing as used here:
https://github.com/llvm/llvm-project/blob/4875e0670926b0a40ce0dd2c3d490b1866889f54/clang/include/clang-c/Index.h#L2243-L2247

Where the cursor can be classified to point to particular data type via an enum. Perhaps we could implement the former suggestion and extend it with the latter.

Issues occur when making use of a build of this repo with xeus-clang-repl on Apple Silicon. An initial investigation found the following issue

• Wrong file extension when building on Apple Silicon (at least on my machine the file extension needed to be .dylib)

This issue is related to compiler-research/xeus-clang-repl#76
A pull request will be created shortly to suggest a fix for the above issues