chromium: use clang >= 16

[MaxIhlenfeldt]

Chromium is going to switch to using C++20 soon (one or two months). According to Google's Peter Kasting, "Anything before clang 16 is basically not going to work".

Here's the current clang versions that we use:

• dunfell: 12
• kirkstone: 14
• mickledore: 15

i.e. every Yocto release is currently using a version that's going to cause a lot of problems very soon.

Maybe it's possible to provide clang 16 in a similar way to the recently introduced possibility of using Node 14 on dunfell?

[MaxIhlenfeldt]

I learned about this by coincidence talking to Peter. It's quite urgent, as the switch to C++20 seems to be only a few major versions away from being released 😅

[kraj]

using clang16 just for chromium might be fine for dunfell and kirkstone however, this would need work since we wont be able to build rest of OE packages with clang16 without major surgery.

[MaxIhlenfeldt]

we wont be able to build rest of OE packages with clang16 without major surgery.

I would have expected using a newer clang version to be backwards compatible, what kind of problems can arise from updating clang?

using clang16 just for chromium might be fine

Is it possible to use clang16 just for chromium and use the default clang version otherwise?

[kraj]

we wont be able to build rest of OE packages with clang16 without major surgery.

I would have expected using a newer clang version to be backwards compatible, what kind of problems can arise from updating clang?

Think of this, we are trying to use a compiler released in 2023 to compile packages which were predominantly released
in 2020, clang-16 was not around back then, so these packages may have code which new clang compiler will find errors
in or expose errors which older compiler was incapable of. This is commonly seen issue when mixing newer compiler with older source code of packages.

using clang16 just for chromium might be fine

Is it possible to use clang16 just for chromium and use the default clang version otherwise?

I think yes. If we create dunfell_clang16 then this branch may only be used to compile chromium alone.
this will be troublesome for folks who are using clang as default system compiler with dunfell and also using
chromium and want to upgrade to latest chromium. They will have to switch system compiler to gcc and select
clang only for chromium for best results.

[MaxIhlenfeldt]

This is commonly seen issue when mixing newer compiler with older source code of packages.

I had feared that my expectation regarding backwards compatibility might be a bit optimistic, thanks for confirming.

this will be troublesome for folks who are using clang as default system compiler with dunfell and also using
chromium and want to upgrade to latest chromium. They will have to switch system compiler to gcc and select
clang only for chromium for best results.

Why is that? Is it not possible to use clang 12 as the default system compiler and clang 16 for Chromium only? Either way, I suppose it'd be a reasonable restriction, given that the alternative is not supporting Chromium on dunfell at all.

[MaxIhlenfeldt]

Updating to m115 gives more errors that presumably wouldn't happen with clang 16:

| In file included from ../../chrome/test/chromedriver/capabilities.cc:5:
| In file included from ../../chrome/test/chromedriver/capabilities.h:10:
| In file included from /home/gitlab-runner/yocto-chromium/builds/ci-chromium-wayland-qemuarm64-mickledore/tmp-glibc/work/cortexa57-oe-linux/chromium-ozone-wayland/115.0.5790.102-r0/recipe-sysroot/usr/include/c++/v1/map:541:
| In file included from /home/gitlab-runner/yocto-chromium/builds/ci-chromium-wayland-qemuarm64-mickledore/tmp-glibc/work/cortexa57-oe-linux/chromium-ozone-wayland/115.0.5790.102-r0/recipe-sysroot/usr/include/c++/v1/__node_handle:63:
| In file included from /home/gitlab-runner/yocto-chromium/builds/ci-chromium-wayland-qemuarm64-mickledore/tmp-glibc/work/cortexa57-oe-linux/chromium-ozone-wayland/115.0.5790.102-r0/recipe-sysroot/usr/include/c++/v1/memory:846:
| In file included from /home/gitlab-runner/yocto-chromium/builds/ci-chromium-wayland-qemuarm64-mickledore/tmp-glibc/work/cortexa57-oe-linux/chromium-ozone-wayland/115.0.5790.102-r0/recipe-sysroot/usr/include/c++/v1/__memory/allocate_at_least.h:13:
| /home/gitlab-runner/yocto-chromium/builds/ci-chromium-wayland-qemuarm64-mickledore/tmp-glibc/work/cortexa57-oe-linux/chromium-ozone-wayland/115.0.5790.102-r0/recipe-sysroot/usr/include/c++/v1/__memory/allocator_traits.h:298:9: error: no matching function for call to 'construct_at'
|         _VSTD::construct_at(__p, _VSTD::forward<_Args>(__args)...);
|         ^~~~~~~~~~~~~~~~~~~
| /home/gitlab-runner/yocto-chromium/builds/ci-chromium-wayland-qemuarm64-mickledore/tmp-glibc/work/cortexa57-oe-linux/chromium-ozone-wayland/115.0.5790.102-r0/recipe-sysroot/usr/include/c++/v1/__config:658:17: note: expanded from macro '_VSTD'
| #  define _VSTD std
|                 ^
| /home/gitlab-runner/yocto-chromium/builds/ci-chromium-wayland-qemuarm64-mickledore/tmp-glibc/work/cortexa57-oe-linux/chromium-ozone-wayland/115.0.5790.102-r0/recipe-sysroot/usr/include/c++/v1/vector:818:21: note: in instantiation of function template specialization 'std::allocator_traits<std::allocator<BrandVersion>>::construct<BrandVersion, const std::string &, const std::string &, void, void>' requested here
|     __alloc_traits::construct(this->__alloc(), _VSTD::__to_address(__tx.__pos_),
|                     ^
| /home/gitlab-runner/yocto-chromium/builds/ci-chromium-wayland-qemuarm64-mickledore/tmp-glibc/work/cortexa57-oe-linux/chromium-ozone-wayland/115.0.5790.102-r0/recipe-sysroot/usr/include/c++/v1/vector:1631:9: note: in instantiation of function template specialization 'std::vector<BrandVersion>::__construct_one_at_end<const std::string &, const std::string &>' requested here
|         __construct_one_at_end(_VSTD::forward<_Args>(__args)...);
|         ^
| ../../chrome/test/chromedriver/capabilities.cc:358:16: note: in instantiation of function template specialization 'std::vector<BrandVersion>::emplace_back<const std::string &, const std::string &>' requested here
|         brands.emplace_back(*brand, *version);
|                ^
| /home/gitlab-runner/yocto-chromium/builds/ci-chromium-wayland-qemuarm64-mickledore/tmp-glibc/work/cortexa57-oe-linux/chromium-ozone-wayland/115.0.5790.102-r0/recipe-sysroot/usr/include/c++/v1/__memory/construct_at.h:33:38: note: candidate template ignored: substitution failure [with _Tp = BrandVersion, _Args = <const std::string &, const std::string &>]: no matching constructor for initialization of 'BrandVersion'
| _LIBCPP_HIDE_FROM_ABI constexpr _Tp* construct_at(_Tp* __location, _Args&&... __args) {
|                                      ^
| 1 error generated.

(I suspect the substitution error mentioned at the end doesn't happen with clang >= 16.)

As already mentioned, there will be more errors as slowly the code base uses more and more C++20 features (this might not even be the only error of this kind in m115). What's the plan for moving to using clang 16 on dunfell, kirkstone and mickledore?

[rakuco]

FWIW, I've been toying with a dunfell-clang14 branch that's basically cherry-picking a ton of commits from meta-clang's kirkstone branch. chromium-x11 and chromium-ozone-wayland built fine, but I haven't tried running the binaries yet.

[MaxIhlenfeldt]

That sounds promising! But I fear using clang 14 won't get rid of all the errors, as even mickledore with clang 15 is causing problems :/

[rakuco]

That's probably true. At this point I'm trying to do this as a learning experience; if this works, we can have both dunfell and kirkstone using the same compiler version, in which case moving both to a newer version.

With that said, clang 15 is less than a year old, so my only fear is that we'll always spend a non-trivial amount of time chasing compiler failures simply because Chromium's always using LLVM's main branch. Building the Chromium recipe with Chromium's LLVM is probably a no-go :/

[MaxIhlenfeldt]

if this works, we can have both dunfell and kirkstone using the same compiler version, in which case moving both to a newer version.

Ah, good point. That does sound useful.

so my only fear is that we'll always spend a non-trivial amount of time chasing compiler failures simply because Chromium's always using LLVM's main branch

It did work relatively well in the past, didn't it? I think what's currently causing the increased amount of problems is upstream's switch to C++20, which isn't well supported before clang 16.

[MaxIhlenfeldt]

How should we proceed here now that meta-clang has a dunfell-clang14 branch? The update to 117 once more needs many build fixes that wouldn't be needed with clang 16. And while these fixes usually are trivial, they still take up a lot of my time 🙁