Thread: Future Postgres 15 and Clang 15

<sigh>

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:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=seawasp&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);

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:-/

-- 
Fabien.

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