Parse callbacks should be able to tell whether an item is allowlisted

Open
  • Is something wrong?
#3,539 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
c, rust
Domain
tooling

Research direction

The relevant entry points are the parse callbacks, in particular blocklisted_type_implements_trait, which the reporter says does not fire for every blocklisted item. The reproduction is the linked bl-proto-ref/build.rs, whose generated bl_sockaddr.rs references SOCKADDR_FIELDS types that were never emitted. Done would mean an API that tells callbacks whether an item will be emitted, including recursively allowlisted types, and this needs maintainer input on the design first.

Written by the indexing model from the issue text.

Description

Right now, it appears that parse callbacks are called on everything found in the input headers, whether or not the item involved is actually going to be emitted. This is inconvenient for using parse callbacks to emit additional information about the types that you are going to emit -- example here: https://codeberg.org/zwol/ip_banhammer/src/commit/2108977c637fb3a3af22be7ffeb12674bbe1a1fe/bl-proto-ref/build.rs If you run this as it is right now and look at the generated bl_sockaddr.rs, you'll see that the SOCKADDR_FIELDS constant refers to a whole bunch of types that we didn't generate bindings for, they just happen to be declared in the same C system headers as the ones that are allowlisted. (Ignore make_libblocklist_bindings in the same file, that's unrelated to the issue.)

I imagine that many of the parse callbacks are happening too early to know whether the top-level item is going to be emitted or not, but it would be really helpful to have some way to be informed of the set of things that will (or, equivalently, won't) be emitted. (In the example, you can see I tried to use blocklisted_type_implements_trait for that, but it didn't get called for all the blocklisted items so it didn't help.)

I can't just hardcode the set of things that are allowlisted up front, because in this case I need to get the recursively allowlisted types also.

Dominant language
Rust
Stars
5.3k
Forks
846
Avg merge
2d 6h
Merged PRs (30d)
11

Getting set up

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.

More from rust-lang/rust-bindgen

All issues in rust-lang/rust-bindgen

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.