Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Proposal: `MethodPrefix` in llcppg.cfg

Abierto
  • ¿Algo no está bien?
#1,061 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
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
c, go
Área
devtools

Línea de trabajo

This is a design proposal, so confirm with maintainers before coding. Start with how TypeAbbr and FuncPrefix are read from llcppg.cfg, then find the step where a global function judged to be a method of a type has its prefix removed. The fix should strip a literal per-type prefix there and leave other types unchanged. Done when gzbuffer on GzFile becomes Buffer and existing configs produce the same output.

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

Descripción

configuration

Summary

Add a MethodPrefix field to llcppg.cfg that lets a library author declare, per type, a literal prefix to remove from the names of that type's methods. It targets older C libraries such as zlib, where the type is encoded in the function name by a short prefix (gz for gzFile) that cannot be recovered by lexical analysis.

"MethodPrefix": {
    "GzFile": "gz"
}

With this configuration, gzbuffer(gzFile file, unsigned size) becomes (*GzFile).Buffer.

Background

When llcppg turns a global C function into a method, it has to decide what the method is called. For most modern C libraries the type name is embedded in the function name, separated from the rest by _ or by a camel-case boundary, and llcppg strips it using lexical rules:

CXTargetInfo
clang_getTranslationUnitTargetInfo(CXTranslationUnit CTUnit);

Here TranslationUnit appears as a whole word inside the name, so after the library prefix (clang_) and the type name are removed, what remains is TargetInfo. Type abbreviations (TypeAbbr) extend this for names where the type is written in a shortened form.

All of these mechanisms work at the lexical level: they only remove things that form complete, well-delimited words.

Problem

Older libraries often do not follow that convention. In zlib:

int gzbuffer(gzFile file, unsigned size);
int gzread(gzFile file, voidp buf, unsigned len);
int gzclose(gzFile file);

The receiver type is gzFile, but the function name only carries the two-letter prefix gz, glued directly to the rest of the name (gz + buffer). There is no _, no case change, and no complete type word to match. Because gz is not a lexically valid unit, neither the built-in type-name stripping nor TypeAbbr can remove it, and the generated method ends up with an awkward name like Gzbuffer.

The existing FuncPrefix cannot help either: it is global rather than per type, and it removes the prefix from function names whether or not the function becomes a method of that type.

Proposal

MethodPrefix is a map from a type's Go name to the prefix to strip from that type's method names.

{
    "MethodPrefix": {
        "GzFile": "gz"
    }
}

Key points of the design:

  • The key is the type's goName, consistent with TypeAbbr. In the example above, the C type gzFile has the Go name GzFile.
  • The value is a literal prefix, written the way it appears in the C function name. Following the convention used throughout llcppg.cfg, Prefix and Suffix fields ignore lexical boundaries, while all other concepts work within them. MethodPrefix is a Prefix field, so gz is removed from gzbuffer even though gz and buffer are not separated by any word boundary.
  • Matching is on the C function name, case-sensitive, and the prefix must match at the start of the name.
When it runs

MethodPrefix is applied at the point where the type's goName and cName are both known, but the method's name is still in its original C style (before any conversion to Go-style camel case). In terms of the function-name pipeline, it takes part in the step where a global function that has been judged to be a method gets its type-related prefix removed.

After the prefix is removed, the remainder goes through the normal C-style to Go-style conversion, so the result is exported and camel-cased as usual:

C function Receiver Method
gzbuffer gzFile (*GzFile).Buffer
gzread gzFile (*GzFile).Read
gzclose gzFile (*GzFile).Close
What it does not do
  • It does not decide whether a function is a method. That is still determined by the existing mechanisms (the receiver is the first parameter, and so on). MethodPrefix only affects the name of a function that has already been classified as a method of the given type.
  • It does not change functions that are not methods of that type. gzopen(const char *path, const char *mode) returns a gzFile but does not take one as its first parameter, so it remains a plain function and MethodPrefix does not touch it.

Behavior details

  • No match. If a method of the type does not start with the configured prefix, MethodPrefix has no effect on that name, and the usual lexical rules apply as before.
  • Match. If the prefix matches, it is removed and the remainder is used as the base of the method name. The built-in lexical type-name stripping is not applied on top of it for that name, since the author has explicitly said how this type's methods are prefixed.
  • Empty remainder. If removing the prefix would leave nothing (a function named exactly gz), the prefix is not applied.
  • Types without an entry. Behave exactly as today. The option is purely additive, and existing configurations keep working unchanged.

Relationship to other options

Option Scope Lexical rules Role
FuncPrefix all functions none (literal) Strips a library-wide prefix such as clang_
TypeAbbr per type yes Strips the type name or an abbreviation of it when it appears as a word
MethodCheck per type family pattern-based Decides whether a function belongs to a logical type
MethodPrefix (new) per type none (literal) Strips a type-specific prefix that is not a word

MethodPrefix fills the one gap the others leave: a type-specific prefix that has no lexical structure.

Example: zlib

{
    "name": "zlib",
    "MethodPrefix": {
        "GzFile": "gz"
    }
}

Generated Go (abridged):

func (p GzFile) Buffer(size c.Uint) c.Int
func (p GzFile) Read(buf c.Pointer, len c.Uint) c.Int
func (p GzFile) Close() c.Int

Without the option, the same functions would appear as Gzbuffer, Gzread and Gzclose.

Possible extensions (out of scope)

  • Wildcard or replacement syntax in the value, in the style of the unified name matcher. The literal prefix covers the zlib case, and the matcher can be reused later if a real need appears.
  • Allowing a list of prefixes for a type whose methods are spread over several prefixes. This can be added later by accepting a list in addition to a string without breaking existing configurations.
Lenguaje dominante
Go
Estrellas
39
Forks
13
Merge medio
1 h 33 min
PR fusionados (30 d)
256

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 goplus/llcppg

Todos los issues de goplus/llcppg

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.