rust-lang / rust-lang/rust-bindgen

Callbacks: Give `ItemInfo` a `mangled_name` field. `generated_link_name_override` shouldn't receive the result of `generated_name_override`.

Open
#3,107 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
5.3k
Forks
829
Avg merge
1d 1h
Merged PRs (30d)
15

Description

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?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the ItemInfo definition and the call sites for generated_name_override and generated_link_name_override. Trace how the default and mangled names are produced, then update the callback inputs so link-name generation is independent and ItemInfo exposes the mangled name. Done means both callback behaviors and the new field are covered by the relevant tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.