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

Abierto
  • ¿Algo no está bien?
#3,539 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
c, rust
Área
tooling

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
5.3k
Forks
846
Merge medio
2 d 6 h
PR fusionados (30 d)
11

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rust-lang/rust-bindgen

Todos los issues de rust-lang/rust-bindgen

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.