cl typeName: global rename for special case

[xushiwei]

No description provided.

[fennoai]

Review summary

The change makes prefix stripping on pkgCtx.typeName conditional (removePrefix bool) and, in loadEnum, falls back to the un-stripped name when the stripped name already exists in the package scope. The regenerated golden files confirm the intended effect on llvm-22.1.8: CXCursorKind → CursorKind, CX_CXXAccessSpecifier → CXXAccessSpecifier, and CXBinaryOperatorKind correctly stays CXBinaryOperatorKind because BinaryOperatorKind is already taken.

The direction is sound and the golden output shows the fallback path is genuinely exercised, not dead code. Three points are worth addressing before merge.

1. The fallback result is never re-checked (cl/enum.go:62-65, [P1]). The guard tests one candidate (the stripped name) and, on collision, adopts typeName(origName, false) without looking it up. If two enums normalize to the same un-stripped Go name, or the un-stripped name is otherwise occupied, a duplicate type declaration is emitted and surfaces only as a downstream build error in the generated package. A second Lookup on the fallback (and a diagnostic when that also fails) makes the guard complete.

2. The same collision class is unguarded at the other typeName call sites. typedef.go:39, class.go:85, union.go:66 and import.go:180 all call typeName(..., true) with no fallback. This PR broadens the prefix list to two entries (["CX_", "CX"]), which makes strip-to-the-same-name more likely for those declaration kinds too — yet only enums gained the guard. Either apply the fix consistently or state in the description that typedef/class/union are a known follow-up.

3. Collision handling is order-dependent. The first declaration to claim a stripped name wins it, and every later colliding declaration gets the name with its prefix retained, so the generated names depend on traversal order rather than on any explicit priority. Worth a comment stating the intended rule so a future reader does not mistake it for accidental behavior.

Documentation nits (non-blocking): the removePrefix parameter is undocumented on an exported-ish helper now called from five sites, and compile.go:117-125 / tool/gen.go still describe TypePrefix/EnumPrefix/FuncPrefix as "the prefix" though they are ordered []string where the first match wins (rmPrefix in cl/ctx.go:350). The new ["CX_", "CX"] fixture depends on exactly that ordering.

No performance or security concerns: the added Scope().Lookup is a single O(1) map lookup per named enum (outside the constant loop), the config fixture is not a hot path, and C identifiers cannot smuggle non-identifier characters through cstyleToGo.

[fennoai]

The fallback name is adopted without a second Lookup. If the un-stripped name is also occupied (e.g. two enums that differ only in their prefix), a duplicate type declaration is emitted and only shows up later as a build error in the generated package. Consider re-checking the fallback and emitting a diagnostic when it too collides:

typeName := ctx.typeName(origName, true)
if pkgTypes.Scope().Lookup(typeName) != nil {
    if alt := ctx.typeName(origName, false); pkgTypes.Scope().Lookup(alt) == nil {
        typeName = alt
    } else {
        log.Println("enum name conflict:", origName)
    }
}