Fix pascal/camel case identifier tokens to allow underscores#68
Open
mallyskies wants to merge 1 commit into
Open
Fix pascal/camel case identifier tokens to allow underscores#68mallyskies wants to merge 1 commit into
mallyskies wants to merge 1 commit into
Conversation
_pascalCaseIdentifier and _camelCaseIdentifier only allowed underscores in the leading run of characters, not after a case shift. This silently truncated any type/constructor reference shaped like CAPS_Suffix (e.g. POTI_Reel) at the first underscore wherever it appeared as a super_class_name, interface_name, or constructor target, since those fields resolve through type_name -> _pascalCaseIdentifier. Also widen _pascalCaseIdentifier's leading class to accept '_', since Haxe type names may start with an underscore (module-private types) per the language spec.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes two related lexing bugs in
_pascalCaseIdentifier/_camelCaseIdentifierthat cause any identifier shaped likeFoo_Bar(or a leading-underscore type name) to be silently truncated or rejected wherever it's used as atype_name—extends/implementstargets,new X(...)constructors, and import paths.Truncated at the first underscore after a case shift
_pascalCaseIdentifieroriginal trailing character class excludes_, so once the leading run of uppercase letters ends, an underscore stops the match.class Foo extends Bar_Baz {}parsesBar_Bazas justBar, leaving_Bazas a separateERRORnode. Same issue in_camelCaseIdentifierfor lowerCamel names with an underscore after the first case shift (e.g.fooBar_Baz).Confirmed via direct parse — before this fix:
class Foo extends Bar_Baz {}produces
type_name: 'Bar'followed by anERRORnode for_Baz.Type names starting with
_were rejected outrightPer the Haxe manual: "Type names must start with an upper-case letter
A-Zor an underscore_."_pascalCaseIdentifier's leading character class was[A-Z]+, which can never match a leading_, so a module-private type name (Haxe's_Fooconvention) fails to lex as atype_namereference at all — not truncated, just unrecognized.Fix
Verified locally by regenerating the parser and re-parsing extends/implements/new X(...)/leading-underscore cases — all resolve with no ERROR nodes. A downstream tree-sitter consumer (a Haxe-aware code-graph extractor) now correctly resolves inherits/instantiation edges for identifiers using this naming convention, where previously they silently collapsed to whatever text preceded the first underscore. Not including the regenerated src/ output in this PR itself, since the project's convention (per past merged PRs) is grammar-source-only and letting the maintainer regenerate.