Future Postgres 15 and Clang 15

On Fri, Jun 24, 2022 at 8:35 PM Fabien COELHO <coelho@cri.ensmp.fr> wrote:

Just a note/reminder that "seawasp" has been unhappy for some days now
because of yet another change in the unstable API provided by LLVM:

Hi Fabien,

Yeah, I've started on the changes needed for opaque pointers (that's
the change that's been generating warnings since LLVM14, and now
aborts in LLVM15), but I haven't figured out all the puzzles yet. I
will have another go at this this weekend and then post what I've got,
to show where I'm stuck.

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=seawasp&amp;dt=2022-06-23%2023%3A18%3A17

llvmjit.c:1115:50: error: use of undeclared identifier 'LLVMJITCSymbolMapPair'
LLVMOrcCSymbolMapPairs symbols = palloc0(sizeof(LLVMJITCSymbolMapPair) * LookupSetSize);

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

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...

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.