[foreign] Supporting different versions of LLVM

[Maurizio Cimadamore]

Hi Jorn,
thanks for following up issues with the LLVM community. (another area 
where it would be nice to get some help would be in macro expression 
evaluation - there's an expression evaluation API but doesn't work on 
macros).

I think that, as developers it would be relatively easy to update our 
versions of LLVM. The bigger issue would be in trying and adjusting our 
scripts for the EA builds - while on Linux we build from sources, I 
believe for other platforms we just use ready-made binary snapshots, so 
if we bump clang, these scripts would need to be updated too.

When the time comes, I can ping Erik from the infra team and see if we 
can bump LLVM.

Maurizio


On 29/04/2019 12:44, Jorn Vernee wrote:
> Hi,
>
> Over the weekend I have been looking into a fix for: 
> https://bugs.openjdk.java.net/browse/JDK-8223031
>
> The underlying problem is that the behaviour of one of the libclang 
> function, namely `clang_Cursor_isAnonymous`, was changed to do 
> something very different [1], and I haven't been able to find a good 
> workaround that covers all needed cases.
>
> So, instead I've submitted a patch to clang to add a new function that 
> has the old behaviour [2], which is currently under review and seems 
> to be a-go for commit soon. With a small patch on our side we can make 
> our code work with the new function [3].
>
> While I was at it I also submitted a patch for the incomplete array 
> problem I worked around before [4].
>
> Hopefully these patches will make it into the next LLVM release. But, 
> it brings up the question of which LLVM versions should be supported 
> by us. Currently I'm locally using version 7.0.1 which works fine, and 
> version 8.0.0 is definitely not supported due to the 
> `clang_Cursor_isAnonymous` change. Once a version is released that has 
> [2], we can support that version as well, and with a version that 
> supports [4] we can also remove the incomplete array problem 
> workaround (which is pretty extensive). Though the latter would mean 
> dropping support for earlier LLVM versions as well. I think as long as 
> there's a binary distribution available this will not be a problem. We 
> can update the lib-clang autoconf script to check the LLVM version, 
> and warn about any that are not supported.
>
> How does that sound?
>
> Thanks,
> Jorn
>
> [1] : https://reviews.llvm.org/D54996
> [2] : https://reviews.llvm.org/D61232
> [3] : 
> http://cr.openjdk.java.net/~jvernee/panama/webrevs/8223031/webrev.00/
> [4] : https://reviews.llvm.org/D61239