C parser drops docs under namespace variables defined in another file
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 55/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Área
- documentation, tooling
Línea de trabajo
Rastrea cómo el parser de C gestiona rb_define_const y las definiciones de métodos, comparando su búsqueda de @known_classes local al parser con la búsqueda de enclosure respaldada por el store que usan rb_define_class_under y rb_define_module_under. Verifica el comportamiento con el ejemplo mFoo de dos archivos: las constantes y los métodos definidos después de mFoo en otro archivo deberían aparecer bajo Foo, sin requerir un comentario seed falso.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
C parser drops docs for entries under a namespace variable defined in another file
RDoc's C parser appears unable to resolve extension namespace variables across C files for constants and methods.
Example:
/* foo.c */
VALUE mFoo;
void Init_foo(void) {
mFoo = rb_define_module("Foo");
}
/* constants.c */
rb_define_const(mFoo, "VERSION", rb_str_new_cstr("1.0.0"));
In this shape, RDoc does not know what mFoo means while parsing constants.c, so Foo::VERSION is not documented.
There is partial cross-file support for _under definitions, such as:
/* bar.c */
VALUE cBar = rb_define_class_under(mFoo, "Bar", rb_cObject);
That can work because rb_define_class_under / rb_define_module_under goes through a store-backed enclosure lookup. In other words, when RDoc is creating a class or module, it has a special path that can sometimes find the enclosing C variable from another parsed file or cache.
Constants and methods do not appear to use the same path. They only check the parser-local @known_classes map, and if mFoo is missing, the entry is silently skipped.
A workaround is to add a fake seed comment in each C file:
/* RDoc parses C files independently: mFoo = rb_define_module("Foo") */
Because RDoc scans block comments for rb_define_* patterns, this seeds mFoo => Foo for that file and documentation is generated.
Expected behavior: once mFoo is defined in one parsed C file, later C files should be able to document constants and methods under Foo, or RDoc should provide a documented way to seed cross-file C namespace variables.
- Lenguaje dominante
- Ruby
- Estrellas
- 930
- Forks
- 465
- Merge medio
- 2 d 16 h
- PR fusionados (30 d)
- 28
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de ruby/rdoc
-
RDoc 8.0.0 gem omits `doc/rdoc/example.rb`, which is referenced by the packaged markup documentationAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
ruby/rdoc#1759 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 68/100
ruby/rdoc#1823 · 5 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
misa.G should not be definedAbiertodata error
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
riscv/riscv-unified-db#2648 ·
Los mantenedores suelen responder en 1 día
-
P2 testing
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
Los mantenedores suelen responder en 1 día