Missing fields in nested class with LLVM 22

[dtolnay]

Input header:

class A {
  class I;
};

class A::I {
  int i;
};

Generated correct Rust binding prior to llvm/llvm-project#147835:

#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct A {
    pub _address: u8,
}
#[allow(clippy::unnecessary_operation, clippy::identity_op)]
const _: () = {
    ["Size of A"][::std::mem::size_of::<A>() - 1usize];
    ["Alignment of A"][::std::mem::align_of::<A>() - 1usize];
};
#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct A_I {
    pub i: ::std::os::raw::c_int,
}
#[allow(clippy::unnecessary_operation, clippy::identity_op)]
const _: () = {
    ["Size of A_I"][::std::mem::size_of::<A_I>() - 4usize];
    ["Alignment of A_I"][::std::mem::align_of::<A_I>() - 4usize];
    ["Offset of field: A_I::i"][::std::mem::offset_of!(A_I, i) - 0usize];
};

Generated incorrect Rust binding after that LLVM refactor, which is part of LLVM 22:

#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct A {
    pub _address: u8,
}
#[allow(clippy::unnecessary_operation, clippy::identity_op)]
const _: () = {
    ["Size of A"][::std::mem::size_of::<A>() - 1usize];
    ["Alignment of A"][::std::mem::align_of::<A>() - 1usize];
};
#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct A_I {
    pub _address: u8,
}
#[allow(clippy::unnecessary_operation, clippy::identity_op)]
const _: () = {
    ["Size of A_I"][::std::mem::size_of::<A_I>() - 4usize];
    ["Alignment of A_I"][::std::mem::align_of::<A_I>() - 4usize];
};

The new generated code fails to compile.

error[E0080]: attempt to compute `1_usize - 4_usize`, which would overflow
  --> src/lib.rs:18:21
   |
18 |     ["Size of A_I"][::std::mem::size_of::<A_I>() - 4usize];
   |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ evaluation of `_` failed here

Notice that bindgen clearly knows that A::I is supposed to have size 4, it is just that the generated Rust type for it has size 1, and does not know what the fields are.

[emilio]

So LLVM changed the AST representation in a way that this code no longer deals with it correctly I guess? I'd be curious to know if:

• We're incorrectly bailing here for the inner class or
• There is a warning here about something we are not handling.

[emilio]

Oh, I guess the definition in the example there is outside the parent class, so the first link should actually bail. Maybe the new AST representation isn't correctly exposed to libclang?