Repository navigation
Register the UnicodeString keyword handler - #5
Merged
Merged
Conversation
TmwBasePasLex.Func158 lexes UnicodeString as ptString with ExID ptUnicodeString, the way Func-handlers already treat AnsiString and WideString, but InitIdent never put it in FIdentFuncTable. 'UnicodeString' hashes to 158, which had no entry, so the handler was unreachable (Delphi: H2219 Private symbol 'Func158' declared but never used) and the word lexed as a plain identifier. Declarations parse the same either way. The difference is a typecast: UnicodeString(p^) built a CALL whose callee was an IDENTIFIER, which cannot be told apart from a call to a routine of that name, while AnsiString(p^) and WideString(p^) build a TYPE callee. Now all three do. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
AST.UnicodeStringTypecast parses `s := UnicodeString(p^)` and checks that
the CALL's callee is an ntType named UnicodeString. It fails without the
Func158 registration ("A UnicodeString typecast has a type as its callee.")
and passes with it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
1 participant
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.
Bug.
TmwBasePasLex.Func158lexesUnicodeStringasptStringwith ExIDptUnicodeString, the same wayAnsiStringandWideStringare lexed, butInitIdentnever put it inFIdentFuncTable.'UnicodeString'hashes to 158, which had no entry, so the handler was unreachable (Delphi:H2219 Private symbol 'Func158' declared but never used) and the word lexed as a plain identifier. It has been that way sinceFunc158was added in 8fb608d.Declarations parse the same either way. The difference is a typecast:
Before, the cast could not be told apart from a call to a routine named
UnicodeString.Fix. Add
158: FIdentFuncTable[I] := Func158;.Test.
AST.UnicodeStringTypecastis added toTest/UnitTests. It fails onmain("A UnicodeString typecast has a type as its callee.") and passes with this change. A parse-tree dump of a unit usingUnicodeStringas field, parameter, return and variable type differs only in that typecast callee.Serialization.BinaryRoundTripfails with and without this change under Delphi 10.4 (line_seqcomes back as 0), so it is not related.🤖 Generated with Claude Code