1773630 - ROOT_CLIP_CHAIN error fails in firefox 102.0b5-1 with cbindgen 2.24.2

Status: RESOLVED INVALID

(Core :: Graphics: WebRender, defect)

Description

[voncloft]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

Upgraded bindgen to 2.42.2

Received following error in firefox 102

Actual results:

Got error
1:36.51 In file included from /var/cache/scratchpkg/work/firefox/src/firefox-102.0/accessible/atk/nsMaiInterfaceComponent.cpp:16:
1:36.51 In file included from /var/cache/scratchpkg/work/firefox/src/firefox-102.0/firefox-shared/dist/include/mozilla/dom/BrowserParent.h:23:
1:36.51 In file included from /var/cache/scratchpkg/work/firefox/src/firefox-102.0/firefox-shared/dist/include/mozilla/layout/RemoteLayerTreeOwner.h:17:
1:36.51 In file included from /var/cache/scratchpkg/work/firefox/src/firefox-102.0/firefox-shared/dist/include/nsDisplayList.h:48:
1:36.51 In file included from /var/cache/scratchpkg/work/firefox/src/firefox-102.0/firefox-shared/dist/include/nsCSSRenderingBorders.h:20:
1:36.51 In file included from /var/cache/scratchpkg/work/firefox/src/firefox-102.0/firefox-shared/dist/include/gfxUtils.h:23:
1:36.51 In file included from /var/cache/scratchpkg/work/firefox/src/firefox-102.0/firefox-shared/dist/include/mozilla/webrender/WebRenderTypes.h:11:
1:36.51 In file included from /var/cache/scratchpkg/work/firefox/src/firefox-102.0/firefox-shared/dist/include/mozilla/webrender/webrender_ffi.h:104:
1:36.51 /var/cache/scratchpkg/work/firefox/src/firefox-102.0/firefox-shared/dist/include/mozilla/webrender/webrender_ffi_generated.h:24:33: error: redefinition of 'ROOT_CLIP_CHAIN'

Expected results:

Should have built firefox and not error out

I patched with: https://raw.githubusercontent.com/canonical/firefox-snap/5622734942524846fb0eb7108918c8cd8557fde3/patches/fix-ftbfs-newer-cbindgen.patch

Awaiting results right now

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[voncloft]

patch worked

Comment 3

[Emilio Cobos Álvarez [:emilio]]

This is expected when building an older Firefox with a newer cbindgen unfortunately :(

Comment 5

[Paul Menzel]

There is a typo in the cbindgen version used in this bug. Could it please be corrected to 2.24.2 to avoid confusion?

Comment 6

[Paul Menzel]

This is expected when building an older Firefox with a newer cbindgen unfortunately :(

How do I know the recommended cbindgen version for a specific Firefox release? In the source I found a minimum version:

build/moz.configure/bindgen.configure:    cbindgen_min_version = Version("0.23.0")

I would also expect 0.23.x and 0.24.x to still be compatible, and not break backward compatibility. Is guess there is something special about cbindgen?

Comment 7

[Paul Menzel]

(In reply to Paul Menzel from comment #5)

There is a typo in the cbindgen version used in this bug. Could it please be corrected to 2.24.2 to avoid confusion?

I also did it wrong: 0.24.2 is the correct version. (The current release is 0.24.3.)

Comment 8

[Emilio Cobos Álvarez [:emilio]]

(In reply to Paul Menzel from comment #6)

How do I know the recommended cbindgen version for a specific Firefox release? In the source I found a minimum version:

build/moz.configure/bindgen.configure:    cbindgen_min_version = Version("0.23.0")

The version in that file is guaranteed to build as that's what we use in automation

I would also expect 0.23.x and 0.24.x to still be compatible, and not break backward compatibility. Is guess there is something special about cbindgen?

I'm very mindful of cbindgen doing breaking changes. 0.23.x and 0.24.x don't need to be backwards compatible between them generally tho (it's special with 0.* versions), but in any case in this situation I don't think it's reasonable to blame it on the tool. The issue is that cbindgen didn't understand a constant WR used, and someone needed that constant and added it manually. Instead of using another name (which would've prevented this issue) they used the exact same name cbindgen would've generated. So when cbindgen improved and was able to generate that constant, well, you get this bug. If we consider a breaking change in cbindgen any time we potentially generate new code then ~all cbindgen changes would be breaking...