Hello Thomas,
>> llvmjit.c:1233:81: error: too few arguments to function call, expected 3, have 2
>> ref_gen = LLVMOrcCreateCustomCAPIDefinitionGenerator(llvm_resolve_symbols, NULL);
>
> Ah yes, I hadn't seen that one yet. That function grew a "Dispose"
> argument, which we can just pass NULL for, at a guess:
>
> https://github.com/llvm/llvm-project/commit/14b7c108a2bf46541efc3a5c9cbd589b3afc18e6
I agree with the guess. Whether the NULL induced semantics is the right
one is much less obvious…
>> The question is: should pg 15 try to be clang 15 ready? I'm afraid yes, as
>> LLVM does 2 releases per year, so clang 15 should come out this Fall,
>> together with pg 15. Possibly other changes will come before the
>> releases:-/
>
> OK let's try to get a patch ready first and then see what we can do.
> I'm more worried about code that compiles OK but then crashes or gives
> wrong query results (like the one for 9b4e4cfe) than I am about code
> that doesn't compile at all (meaning no one can actually ship it!). I
> think the way our two projects' release cycles work, there will
> occasionally be short periods where we can't use their very latest
> release, but we can try to avoid that...
Yep. The part which would worry me is the code complexity and kludges
induced by trying to support a moving API. Maybe careful header-handled
macros can do the trick (eg for an added parameter as above), but I'm
afraid it cannot always be that simple.
--
Fabien.