fix access to identifiers that are reserved keywords

[ajreckof]

Fixes #61981

All reserved keywords listed here were interpreted as tokens and returned false when tested with is_identifier(). So i made it possible to indicate that a token can be interpreted as an identifier whatever is type. Then in parse_attribute when we know we want exclusively identifiers i marked keywords as identifiers.

[ajreckof]

I just realised that instead of creating a variable to mark them as identifier i could directly change the type of the token as the function that gets the identifier from the token isn't using the type but another variable which store the string directly.
Changing the type will make clearer code as it will make only changes in the get_attribute function

[anvilfolk]

I've never fooled around with the tokenizer so I don't feel confident reviewing :)

Couple of thoughts though!

1. Is there a chance you could add a couple of tests that showcase this working and so the same error doesn't creep back up later?
2. Might there be a situation where something that should be a reserved name can now become just an identifier and cause a bug? Or is that just not possible?

[ajreckof]

1. Is there a chance you could add a couple of tests that showcase this working and so the same error doesn't creep back up later?

That seems like a super good idea I'll try to make some but i don't know how to make one so I'll have to look into it.

2. Might there be a situation where something that should be a reserved name can now become just an identifier and cause a bug? Or is that just not possible?

If it reaches this point and it is not interpreted as an identifier it will just raise an error at the next line. That's why we can here safely modify it.

[anvilfolk]

I tried looking through the source code some more to try to give this a review but it's a little too much for me atm :)

The added test looks good though! From now we can forever make sure that you can use reserved keywords as dictionary keys in Lua-style accessors!

[anvilfolk]

Actually, I ran this in debug mode and I do believe that it makes sense! :)

The function changed is already specifically for attribute lookups. The changes make sure that if what comes after the . is basically text (the call to is_node_name()), then it should be interpreted as an identifier. Again, only specifically within the context of an attribute lookup, i.e. base.attribute.

Anything else that isn't text, when is_node_name() returns false, will still raise an error due to the consume function wanting to see an identifier there.

[adamscott]

Approved by the GDScript team on a PR review meeting.

Thanks for your contribution!

(as discussed, the PR will be ready when more cases will be added to the test)

[YuriSizov]

(as discussed, the PR will be ready when more cases will be added to the test)

Marked as a draft until then. Feel free to mark as ready when appropriate.

[adamscott]

It's ready to review! Hurray! 🎉

[YuriSizov]

Thanks!