Rust-analyzer deduces an incorrect struct layout, increasing stated size

rust-analyzer version: rust-analyzer 1.99.0-nightly (73dc916 2026-08-01)

rustc version: rustc 1.99.0-nightly (73dc9167f 2026-08-01)

editor or extension: Debian 13, occurs on Kate (LSP)

relevant settings: default nightly

repository link (if public, optional): N/A

code snippet to reproduce:

use std::{mem::ManuallyDrop, ptr::NonNull};

const TREE_ORDER: usize = 7;
const TREE_MIN_KEYS: usize = 3;
const TREE_MAX_KEYS: usize = 6;

pub struct Tree<T> {
    root: Box<Node<T>>
}

union NodeChildren<T> {
    nodes: [ManuallyDrop<Box<Node<T>>>; TREE_ORDER],
    leaves: [ManuallyDrop<Box<Leaf<T>>>; TREE_ORDER]
}

#[repr(C)]
struct Node<T> {
    children: NodeChildren<T>,
    parent: Option<NonNull<Node<T>>>,
    /// NOTE: keys here are stored as relative,
    /// such that the first leaf under this node is index 0.
    /// This allows O(log N) insertion.
    keys: [usize; TREE_MAX_KEYS],
    num_keys: usize,
    depth: usize
} impl<T> Node<T> {
    fn insert_node(&mut self, node: Box<Node<T>>) {

    }
}

struct Leaf<T> {
    inner: Vec<T>
}

When compiled, the struct Node<T> is 128 bytes, but rust-analyzer claims it is 136 due to adding 8 bytes of padding between children and parent. The same occurs without #[repr(C)], except that the fields are reordered (so the padding is between children and keys).

Start by reproducing the issue with the Rust snippet in the report and compare the compiled Node size with rust-analyzer's reported layout. Trace the layout-size calculation for this union-containing struct, then verify that the reported size is 128 bytes rather than 136 bytes and that the behavior without #[repr(C)] remains correct.