Closed paperdave closed 2 months ago
Adding .builtin
to the assertion gets rid of that panic, but causes another in the next call to identifierIndexToLoc
, as there isn't an "@" in the expected location:
Removing the assertion from identifierIndexToLoc
then causes other problems later on. I tried making identifierTokenToNameLoc
return ?Loc
and updating all of the call sites with an appropriate orelse return
, orelse return null
, or else continue
, etc. throughout the rest of the project, but this ended up breaking some existing logic and causing a different assert to trigger later on here. Not sure what the right solution is, this is an interesting edge case.
@WillLillis A non disruptive fix could be as simple as https://github.com/llogick/zls/commit/8b86b32f42e080b7873edd4cb4d4b035f017d996
@WillLillis A non disruptive fix could be as simple as llogick@8b86b32
@llogick I guess that would do it, nice! Kinda mad I missed that now :laughing:
Zig Version
0.14.0-dev.1511+54b668f8a
ZLS Version
0.14.0-dev.147+dd78968
Client / Code Editor / Extensions
No response
Steps to Reproduce and Observed Behavior
Expected Behavior
no crash. i think the mistake is simply that the token can be a builtin identfier in addition to a regular identifer. though maybe other tokens can exist here
Relevant log output