-
-
Notifications
You must be signed in to change notification settings - Fork 212
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
Add return values when generating virtual methods #207
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for this PR! 🙂
- It looks like you copy-pasted a lot of code from other parts of
class_generator.rs
. Would it be possible to reuse that code instead, so it's only defined once -- if necessary with extra functions? - Could you maybe add a test that uses a method with a return type? There are existing tests in
itest/rust/src/virtual_methods_test.rs
.
Also, in the end please squash commits to 1 😉
a minor note, many of these virtual methods will likely not work until #204 is merged. basically any virtual method call that takes/returns anything but pass-by-value types are currently broken (excluding the receiver), which likely includes the one you're referencing too. as a workaround, string types, arrays, and dictionaries need to have a clone/share |
I'll wait for #204 to move on before fixing the PR, then 😃 |
I implemented a basic test that calls an overloaded virtual method. The test passes, but I now get the following warning:
@SayakS Is this the kind of thing you are fixing on #204, or is it something I need to look at? |
This should be fixed by #204 yes. if you want you can try and see if it does make this test pass, i can't really test it in that PR since it uses a return type. It would actually be pretty good to have tested. |
Trying with latest CI changes... bors try |
tryBuild failed: |
let output = obj.bind().get_configuration_warnings(); | ||
assert!(output.contains("Hello".into())); | ||
assert_eq!(output.len(), 1); | ||
obj.bind_mut().queue_free(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line missing was the cause of the memory leak and, therefore, of the pipeline failing. Another way of solving the memory leak would be to add the obj
node to the test_context
which, I guess, gets cleaned at the end of the test. I went for queue_free
because it looked more concise, but I do not know if there is a recommended practice here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh yeah no that makes sense. nodes outside of the scene tree need to be manually freed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use free()
directly, no? If yes, that should be preferred over queue_free()
.
Also, you can apply that directly on the Gd
pointer:
obj.free();
c56ab9a
to
5e255f1
Compare
I added a test and refactored the code to avoid repetitions. I also rebased against master and squashed the commits. I think this is ready for review. I haven't seen issues regarding #204. Just to be sure, I tested locally with both this PR and #204 merged together and the tests passed all the same. The memory leak I encountered earlier had nothing to do with #204, but was due to me not cleaning after myself. See my comment above. |
bors try |
tryBuild succeeded: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Looks mostly good to me 🙂
At first sight I was a bit concerned that the is_virtual
code path in make_function_definition()
adds a lot of special-casing for relatively few functionality, as it doesn't use a lot of the function codegen logic. But overall I think it's nice to handle those things in one place, and it can also prevent bugs like this one. Thanks for the refactoring! 👍
godot-codegen/src/class_generator.rs
Outdated
(true, _, _) => { | ||
quote! { | ||
unimplemented!() | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you maybe move this to the top?
Then it's immediately clear that no more statements handle is_virtual == true
.
let output = obj.bind().get_configuration_warnings(); | ||
assert!(output.contains("Hello".into())); | ||
assert_eq!(output.len(), 1); | ||
obj.bind_mut().queue_free(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use free()
directly, no? If yes, that should be preferred over queue_free()
.
Also, you can apply that directly on the Gd
pointer:
obj.free();
5e255f1
to
9822843
Compare
Done 👍 |
Fixes godot-rust#190 Some node methods are expected to return values. The corresponding virtual methods, however, do not reflect that. For instance, this is the virtual method `Node.get_configuration_warnings` before this commit: ```rust fn get_configuration_warnings(&self) { unimplemented!() } ``` This is the same method with this commit: ```rust fn get_configuration_warnings(&self) -> PackedStringArray { unimplemented!() } ``` This commit makes `godot_codegen::clas_generator::make_function_definition` and `make_return` aware of virtual method. It also adds a test making sure we can call a virtual method that has a return value.
9822843
to
e81d5d1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot!
bors r+
Build succeeded: |
Fixes #190
Some node methods are expected to return values. The corresponding virtual methods, however, do not reflect that.
For instance, this is the virtual method
Node.get_configuration_warnings
before this commit:This is the same method with this commit:
This commit adapts what I think is the relevant code from
godot_codegen::class_generator::make_method_definition
intomake_virtual_method
.Note that I am very unfamiliar with most of the code I had to touch here as well as with the project.