-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GDScript 2.0 - multiline lambdas not supported #191
Comments
Multiline lambdas are currently not supported. They won't be anytime soon as it requires writing a custom lexer to avoid ambiguity on the parser level. |
Just out of curiosity, what is the ambiguity? |
As far as I remember the clash was on newlines/indent/dedent. The key thing is to get proper indent/dedent when in |
So what is the current way to work around this? As this seems to be a lexer error, we can't really |
You can workaround it by having lambda returning one bing expression, or you can use As for exempting blocks of code from the whole linting process - it's not possible atm. |
Thanks for letting me know, and great work providing this toolkit btw. 👍 |
Any movement on this bug? I've got a working 2d grid iterator pattern going, but formatting breaks and throws errors any time I use it, which is a bummer. func damage_all(attack):
for element in attack.keys():
var elemental_damage = func(space, enemy):
if enemy == null: return
enemy.damage(attack[element], element)
if enemy.current_health <= 0:
$enemies.destroy_entity_at(space)
$enemies.for_each(elemental_damage) |
Not yet. |
Same problem here on a maybe more tricky problem var l_add_and_print := func(root_path, name, is_file):
if is_file:
var path = root_path+"/"+name
gut.p(path)
paths.append(path) Error:
Disable the linter is ok but we can't disable the formatter for this problem. |
camera.tween.finished.connect(func():
camera.tween.stop()
# Switch to linear tween for a smoother follow
camera.tween\
.tween_method(set_pos, 0.0, 1.0, time)\
.set_trans(Tween.TRANS_LINEAR)
camera.tween.play()
) |
I can understand not wanting to support Multiline Lambdas if it implies too much work (I've never build a linter or formatter) since a simple workaround is creating a separate function for the callback. However, would it be much harder to work on handling the exception? When parsing multiple files the user doesn't even know which one is causing the error, and it's hard to deduce why it is happening. An error message as the following would be helpful:
At least it will prevent users from writing more duplicate issues about the matter :) |
@Skyway666 that's a good point - I can try exploring that. It's definitely not as simple as writing a single |
@Scony this would help so much! Currently it can be hard to figure out even what type of error is going on. You have to delete the file in halves to try and figure out where the error is coming from. |
Hi, i run into same issue today, but i got a more hard error.
The
The only workaround is to move the inline lambda to a function and use it. |
@MikeSchulze since it does happen on the parser level, the |
Sorry, this page is gone now... Do you mind explaining a little more about how to workaround? Also, I am wondering if it would be able to just add some try/catch block to this error, so that at least the formatter can continue and finish formatting the file regardless of the error, instead of crashing at the point it encounters a lambda function and doesn't format at all. |
As for the workaround, lambda may be written in one line where statements are separated by a semicolon like this:
also, if the lambda has some expression inside, it can be extended to multiple lines like:
As for the try-catch - it's not possible without multiline lambdas support. |
Thanks for the clarification, and looking forward to a authentic solution. Just by the way thank you for all the efforts bringing this amazing toolkit to us. |
@Scony I wholly understand that this issue is very tricky to fix, but a callout in the main documentation that multiline lambdas are currently causing |
That's a very good point - I'll address that, thanks. |
Any news on this subject ? |
It's WIP, you can track progress here: https://github.com/Scony/godot-gdscript-toolkit/commits/multiline-lambdas/ TL;DR the lexer and parser support is done, the formatter support is like 5% done. |
Hi, I wrote EDIT: Nevermind, there was a multiline lambda later on in my code. |
Does this mean that the linter works? Would it be possible to update gdlint to support multi-line lambdas without gdformat? I have some pretty long lambdas so it is difficult to work with them if they are in a single line but I like having a precommit hook run gdlint. I am working around it at the moment but by keeping the non-minified version in a comment but it is pretty hacky. |
Yes, linter should work - but making P.S. I'm not sure but there may be some regression in the parser so if you get parser errors then it won't work for you anyway. |
That makes sense, thanks! |
The support for multiline (multi-statement) lambdas has been merged into There are few not implemented problems, but IMO 99.9% of users should not notice them, so I decided to proceed. Now, I'd like the change to sink in for few days/weeks before I release new If someone here would like to help, I'd appreciate it if someone could install
and write a comment here stating that "in my project it works!" |
Finally!! Thank you so much. It's my hugest problem with this formatter. ❤️ Would you mind elaborating what the few remaining issues are? So that people might help on it. |
In my project it works! This is fantastic - thank you! |
Problem one: Problem two: Both are most likely a bug in the lexer, so hopefully, I can address those fairly easily. |
This is flagged as error on gd-format but completely legit syntax in GDScript 2.0:
Error:
The text was updated successfully, but these errors were encountered: