Also bump Linux Clang baseline to 12.0.1 (was: Bump --enable-compiler-plugins Clang baseline?)

[Stephan Bergmann]

On 15/02/2022 11:00, Stephan Bergmann wrote:
> On 11/02/2022 15:37, Stephan Bergmann wrote:
>> For another, as discussed in yesterday's ESC meeting,
>>
>>>       + Any objections to make that also the general Linux Clang 
>>> baseline?
>>>         + no objections (all)
>>
>> we'll also bump the Linux Clang-w/o-loplugin baseline to 12.0.1 at 
>> that point.  (Otherwise, we would no longer have a Gerrit Jenkins 
>> builder that builds against that baseline, potentially silently 
>> breaking master for people who still use that baseline.  That way, we 
>> will potentially silently break libreoffice-7-2 and libreoffice-7-3 
>> for people who still use those branches' baselines, though; but 
>> chances of actual breakage should be relatively low.)
> 
> Ach, and then there's Android, which I keep forgetting about.
> 
> All our Gerrit Jenkins Android builds (aarch64, arm, x86, x86_64) appear 
> to be done with Clang 8.0.7 (e.g., 
> <https://ci.libreoffice.org/job/gerrit_android_aarch64/14741/> "checking 
> whether Clang is new enough... yes (8.0.7)").  Cloph, is that correct?
> 
> So what we could do is bump the Linux (incl. Android) w/o-loplugin 
> baseline from 5.0.2 to 8.0.7 (and only bump the with-loplugin baseline 
> to 12.0.1).  That way, we would still have Gerrit Jenkins builds that 
> build against the baseline (even though only on Android), to catch 
> problems with Gerrit changes that would no longer build against the 
> baseline.
> 
> For that, we would presumably need to bump master README.md
> 
>> * Android:
>>     * Build: NDK r19c and SDK 22.6.2
> 
> to whatever NDK and SDK combination would provide at least Clang 8.0.7. 
>   Would anybody see any problems with such an Android baseline bump? And 
> could anybody (Cloph?) please provide the details what the new baseline 
> versions in README.md should be (maybe the versions that are actually 
> used on the Jenkins machines)?

Though, taking another look at this, LLVM never released a "Clang 
8.0.7", so it's a bit unclear to me what that would be exactly.  There 
only ever was LLVM/Clang 8.0.1, according to <https://releases.llvm.org/>.

If I download 
<https://dl.google.com/android/repository/android-ndk-r19c-linux-x86_64.zip> 
(the version referenced in our README.md),

> $ android-ndk-r19c/toolchains/llvm/prebuilt/linux-x86_64/bin/clang --version
> Android (5058415 based on r339409) clang version 8.0.2 (https://android.googlesource.com/toolchain/clang 40173bab62ec746213857d083c0e8b0abb568790) (https://android.googlesource.com/toolchain/llvm 7a6618d69e7e8111e1d49dc9e7813767c5ca756a) (based on LLVM 8.0.2svn)
[...]
and if I download 
<https://dl.google.com/android/repository/android-ndk-r20b-linux-x86_64.zip>,

> $ android-ndk-r20b/toolchains/llvm/prebuilt/linux-x86_64/bin/clang --version
> Android (5220042 based on r346389c) clang version 8.0.7 (https://android.googlesource.com/toolchain/clang b55f2d4ebfd35bf643d27dbca1bb228957008617) (https://android.googlesource.com/toolchain/llvm 3c393fe7a7e13b0fba4ac75a01aa683d7a5b11cd) (based on LLVM 8.0.7svn)
[...]

so:

* It looks like those Android Clang builds have their own versioning 
scheme different from the upstream LLVM/Clang scheme.

* Our current Android baseline Clang (from NDK r19c, reporting "clang 
version 8.0.2") is hopefully new enough that it actually is on-par or 
even beyond an upstream LLVM/Clang 8.0.1.

With that, my suggestion would now be to bump the Linux (incl. Android) 
w/o-loplugin baseline to 8.0.1 (rather than that oddball 8.0.7), and 
keep the Android build baseline as-is at "NDK r19c and SDK 22.6.2" 
(whose Clang reports 8.0.2 and would thus pass the bumped 8.0.1 check in 
configure.ac, at least nominally, and hopefully also functionality-wise).