Conversation
In llvm/llvm-project#147835, Clang's AST changed so that a TagType's decl will not necessarily refer to the type's definition, but to the exact declaration which produced the type. For example, in typedef struct S T; struct S { int x; }; the 'struct S' type would refer to the incomplete type decl in the typedef, causing CompInfo to fail to see the type's definition. This patch inserts a call to use the definition when available. It fixes the original test case in #3275 and most of the test failures caused by the Clang change but not all.
emilio
enabled auto-merge
August 27, 2025 14:01
aarongable
pushed a commit
to chromium/chromium
that referenced
this pull request
Aug 28, 2025
This picks up rust-lang/rust-bindgen#3278 and also adds the tests to the build process to catch such problems earlier. Bug: 440975178 Change-Id: Id919ff4d6191ab04267d961eef3e993665788052 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6890874 Commit-Queue: Nico Weber <thakis@chromium.org> Reviewed-by: Nico Weber <thakis@chromium.org> Auto-Submit: Hans Wennborg <hans@chromium.org> Commit-Queue: Hans Wennborg <hans@chromium.org> Cr-Commit-Position: refs/heads/main@{#1507661}
facebook-github-bot
pushed a commit
to facebook/folly
that referenced
this pull request
Sep 2, 2025
Summary: This reverts my folly workaround from {D80186965} because the bindgen fix [bindgen#3278](rust-lang/rust-bindgen#3278) has made it into fbsource's version of bindgen since {D81525185}.
Reviewed By: diliop
Differential Revision: D81525186
fbshipit-source-id: 3d36156e1f913f050f9af26a1938b65025aa8779
47 tasks
This was referenced Mar 18, 2026
d3zd3z
added a commit
to zephyrproject-rtos/zephyr-lang-rust
that referenced
this pull request
Apr 8, 2026
Bindgen 0.70.1 generates opaque 1-byte structs (`_address: u8`) for all Zephyr kernel types (k_sem, k_mutex, k_thread, device, etc.) when built with LLVM/Clang 22. This causes compile-time size assertion overflows for every affected struct. The root cause is an LLVM 22 change (llvm/llvm-project#147835) that made `clang_getTypeDeclaration()` return the forward declaration cursor instead of the definition cursor for types whose definition is separate from their forward declaration. Bindgen 0.70.1 then sees `is_definition() == false`, treats the struct as a forward declaration with no fields, and emits an opaque type. This was reported as rust-lang/rust-bindgen#3264 and fixed in bindgen 0.72.1 via rust-lang/rust-bindgen#3278, which makes `Type::declaration()` follow through to the definition. Signed-off-by: David Brown <david.brown@linaro.org>
d3zd3z
added a commit
to zephyrproject-rtos/zephyr-lang-rust
that referenced
this pull request
Apr 8, 2026
Bindgen 0.70.1 generates opaque 1-byte structs (`_address: u8`) for all Zephyr kernel types (k_sem, k_mutex, k_thread, device, etc.) when built with LLVM/Clang 22. This causes compile-time size assertion overflows for every affected struct. The root cause is an LLVM 22 change (llvm/llvm-project#147835) that made `clang_getTypeDeclaration()` return the forward declaration cursor instead of the definition cursor for types whose definition is separate from their forward declaration. Bindgen 0.70.1 then sees `is_definition() == false`, treats the struct as a forward declaration with no fields, and emits an opaque type. This was reported as rust-lang/rust-bindgen#3264 and fixed in bindgen 0.72.1 via rust-lang/rust-bindgen#3278, which makes `Type::declaration()` follow through to the definition.
levietduc0712
pushed a commit
to levietduc0712/zephyr-lang-rust
that referenced
this pull request
Apr 11, 2026
Bindgen 0.70.1 generates opaque 1-byte structs (`_address: u8`) for all Zephyr kernel types (k_sem, k_mutex, k_thread, device, etc.) when built with LLVM/Clang 22. This causes compile-time size assertion overflows for every affected struct. The root cause is an LLVM 22 change (llvm/llvm-project#147835) that made `clang_getTypeDeclaration()` return the forward declaration cursor instead of the definition cursor for types whose definition is separate from their forward declaration. Bindgen 0.70.1 then sees `is_definition() == false`, treats the struct as a forward declaration with no fields, and emits an opaque type. This was reported as rust-lang/rust-bindgen#3264 and fixed in bindgen 0.72.1 via rust-lang/rust-bindgen#3278, which makes `Type::declaration()` follow through to the definition. Signed-off-by: David Brown <david.brown@linaro.org>
devin-ai-integration Bot
added a commit
to Tym-arch/rustdesk
that referenced
this pull request
Apr 13, 2026
bindgen 0.65 generates opaque structs (with only an `_address` field) for vpx_codec_enc_cfg, aom_codec_enc_cfg and related types when building with newer versions of clang (19+) / LLVM (22), which ship by default on up-to-date Arch Linux and other rolling-release distros. This is a known bindgen bug fixed in 0.72.1 via rust-lang/rust-bindgen#3278. Upgrading from bindgen 0.65 to 0.72 resolves the 64 compilation errors in libs/scrap/src/common/vpxcodec.rs and libs/scrap/src/common/aom.rs. Co-Authored-By: Tym O <oobeda4545@gmail.com>
4 tasks
sarroutbi
added a commit
to sarroutbi/rust-tss-esapi
that referenced
this pull request
Apr 23, 2026
bindgen versions prior to 0.72.1 generate incorrect bindings with LLVM/Clang 22 due to a breaking change in TagType AST representation (rust-lang/rust-bindgen#3264). This causes build failures (FTBFS) for any project using tss-esapi-sys with the generate-bindings feature. The fix landed in bindgen 0.72.1 via rust-lang/rust-bindgen#3278. bindgen 0.72.1 has MSRV 1.70.0, but since it is an optional build dependency (only used with the generate-bindings feature), users relying on pre-generated bindings are unaffected and can continue using Rust 1.66.0. Signed-off-by: Sergio Arroutbi <sarroutb@redhat.com>
This was referenced Jun 2, 2026
This was referenced Jun 30, 2026
GrayJack
pushed a commit
to GrayJack/evil-janet
that referenced
this pull request
Jul 29, 2026
This addresses a problem where newer libclang versions incorrectly create opaque structs, which means upstream crates like `janetrs` can't build using libclang 22. See rust-lang/rust-bindgen#3278
ojeda
added a commit
to Rust-for-Linux/linux
that referenced
this pull request
Aug 3, 2026
Starting with LLVM 22, `clang_getTypeDeclaration()` may return a forward
declaration instead of the type definition. This made `bindgen` generate
opaque types [1][2], which in turn made us fail with e.g.
error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`
--> rust/kernel/module_param.rs:78:46
|
78 | let container = unsafe { &*((*param).__bindgen_anon_1.arg.cast::<SetOnce<T>>()) };
| ^^^^^^^^^^^^^^^^ unknown field
|
= note: available field is: `_address`
This was fixed in `bindgen` 0.72.1 [3].
In order to clarify what is going on and avoid confusion [4][5], add
a warning to `rust_is_available.sh` about it when the versions match,
similar to past warnings like the one removed in:
commit ae64324 ("rust: rust_is_available: remove warning for `bindgen` < 0.69.5 && libclang >= 19.1")
In addition, even if the versions match, check if the issue appears to
not reproduce with the given binaries, to avoid a warning in such a case.
Finally, include tests.
[ Nathan, in parallel, updated the instructions of the LLVM+Rust
kernel.org toolchains [6] so that `--version` is not passed, and thus
the latest `bindgen` is installed by default, which should help to
avoid some of these situations. Thanks!
- Miguel ]
Link: rust-lang/rust-bindgen#3264 [1]
Link: #353 [2] # "Missing fields in nested class with LLVM 22."
Link: rust-lang/rust-bindgen#3278 [3]
Reported-by: Burak Emir <burak.emir@gmail.com>
Link: #1247 [4]
Link: https://lore.kernel.org/rust-for-linux/CABwQupNfMAJOGqRM9ke6tj4f53dCCsBDKU7Vp+zf8mwk7bqt8Q@mail.gmail.com/ [5]
Link: https://mirrors.edge.kernel.org/pub/tools/llvm/rust/ [6]
Tested-by: Burak Emir <burak.emir@gmail.com>
Link: https://patch.msgid.link/20260719120514.159914-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
ojeda
added a commit
to Rust-for-Linux/linux
that referenced
this pull request
Aug 3, 2026
Starting with LLVM 22, `clang_getTypeDeclaration()` may return a forward
declaration instead of the type definition. This made `bindgen` generate
opaque types [1][2], which in turn made us fail with e.g.
error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`
--> rust/kernel/module_param.rs:78:46
|
78 | let container = unsafe { &*((*param).__bindgen_anon_1.arg.cast::<SetOnce<T>>()) };
| ^^^^^^^^^^^^^^^^ unknown field
|
= note: available field is: `_address`
This was fixed in `bindgen` 0.72.1 [3].
In order to clarify what is going on and avoid confusion [4][5], add
a warning to `rust_is_available.sh` about it when the versions match,
similar to past warnings like the one removed in:
commit ae64324 ("rust: rust_is_available: remove warning for `bindgen` < 0.69.5 && libclang >= 19.1")
In addition, even if the versions match, check if the issue appears to
not reproduce with the given binaries, to avoid a warning in such a case.
Finally, include tests.
[ Nathan, in parallel, updated the instructions of the LLVM+Rust
kernel.org toolchains [6] so that `--version` is not passed to
`cargo` for `bindgen`, and thus the latest `bindgen` is installed
by default, which should help to avoid some of these situations.
Thanks!
- Miguel ]
Link: rust-lang/rust-bindgen#3264 [1]
Link: #353 [2] # "Missing fields in nested class with LLVM 22."
Link: rust-lang/rust-bindgen#3278 [3]
Reported-by: Burak Emir <burak.emir@gmail.com>
Link: #1247 [4]
Link: https://lore.kernel.org/rust-for-linux/CABwQupNfMAJOGqRM9ke6tj4f53dCCsBDKU7Vp+zf8mwk7bqt8Q@mail.gmail.com/ [5]
Link: https://mirrors.edge.kernel.org/pub/tools/llvm/rust/ [6]
Tested-by: Burak Emir <burak.emir@gmail.com>
Link: https://patch.msgid.link/20260719120514.159914-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
ojeda
added a commit
to Rust-for-Linux/linux
that referenced
this pull request
Aug 3, 2026
Starting with LLVM 22, `clang_getTypeDeclaration()` may return a forward
declaration instead of the type definition. This made `bindgen` generate
opaque types [1][2], which in turn made us fail with e.g.
error[E0609]: no field `__bindgen_anon_1` on type `bindings::kernel_param`
--> rust/kernel/module_param.rs:78:46
|
78 | let container = unsafe { &*((*param).__bindgen_anon_1.arg.cast::<SetOnce<T>>()) };
| ^^^^^^^^^^^^^^^^ unknown field
|
= note: available field is: `_address`
This was fixed in `bindgen` 0.72.1 [3].
In order to clarify what is going on and avoid confusion [4][5], add
a warning to `rust_is_available.sh` about it when the versions match,
similar to past warnings like the one removed in:
commit ae64324 ("rust: rust_is_available: remove warning for `bindgen` < 0.69.5 && libclang >= 19.1")
In addition, even if the versions match, check if the issue appears to
not reproduce with the given binaries, to avoid a warning in such a case.
Finally, include tests.
[ Nathan, in parallel, updated the instructions of the LLVM+Rust
kernel.org toolchains [6] so that `--version` is not passed to
`cargo` for `bindgen`, and thus the latest `bindgen` is installed
by default, which should help to avoid some of these situations.
Thanks!
- Miguel ]
Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Link: rust-lang/rust-bindgen#3264 [1]
Link: #353 [2] # "Missing fields in nested class with LLVM 22."
Link: rust-lang/rust-bindgen#3278 [3]
Reported-by: Burak Emir <burak.emir@gmail.com>
Link: #1247 [4]
Link: https://lore.kernel.org/rust-for-linux/CABwQupNfMAJOGqRM9ke6tj4f53dCCsBDKU7Vp+zf8mwk7bqt8Q@mail.gmail.com/ [5]
Link: https://mirrors.edge.kernel.org/pub/tools/llvm/rust/ [6]
Tested-by: Burak Emir <burak.emir@gmail.com>
Link: https://patch.msgid.link/20260719120514.159914-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #3275
Fixes #3264
Closes #3277 (included here squashed)