generated_link_name_override and generated_name_override are passed an ItemInfo struct:

pub struct ItemInfo<'a> {
    /// The name of the item
    pub name: &'a str,
    /// The kind of item
    pub kind: ItemKind,
}

The code calling these callbacks (paraphrased):

    let mut name = base_item_name;
    if let Some(overriden_name) = callbacks.generated_name_override(ItemInfo {
        name,
        kind
    }) {
        name = override_name;
    }
    let mangled_name: Option<String> = get_mangled_name(); // Note: currently not made available to the callbacks.

    let link_name: Option<String> = callbacks.generated_link_name_override(ItemInfo {
        name, // Note: given the modified version from generated_name_override.
        kind
    });
    ...

Note that generated_link_name_override's passed name is first modified by generated_name_override. I found this counter-intuitive.
Also, link_name_override is not passed the mangled name at all.

I propose two changes:

1. generated_link_name_override's received ItemInfo will not affected by the previous callback.
   • If a user wants this old behaviour they can simply call their implementation of generated_name_override at the start.
2. ItemInfo will get a new field mangled_name: Option<&str>, providing clang's mangled name for the item.
   • Admittedly, I can only think of two uses so far: mapping incorrect mangled names to correct ones, and gleaning extra information about an item from its mangled name. Regardless, why not provide this to the user just in case it comes in handy? Intuitively, a callback named "link name override" should probably receive the link name that would be inserted by default, no?