Add async method code generation #490

antoyo · 2017-11-12T19:13:43Z

For now, it's usable (tested with gio, gtk and sourceview), but we could improve the heuristic as mentionned in the TODO comment.

The other two things that will be implemented in next PRs will be the annotation to specify what is the finish function when it cannot be guessed and writing Unimplemented next to Cancellable when this type does not exist (i.e. when the user forgets to add it to Gir.toml).

I believe some code should be improved, especially the trampoline code generation.
If you have any other improvements, I'd be glad to hear them.

antoyo · 2017-11-12T19:14:38Z

cc @GuillaumeGomez @EPashkin @sdroege

GuillaumeGomez · 2017-11-12T20:19:02Z

src/analysis/bounds.rs

+    ) -> (Option<String>, Option<String>) {
+        let type_name = bounds_rust_type(env, par.typ);
+        let mut type_string =
+            if async {


I suppose you could write it like this:

if async && async_param_to_remove(&par.name) { return (None, None); } else { type_name.into_string() }

GuillaumeGomez · 2017-11-12T20:20:27Z

src/analysis/bounds.rs

+                        info_for_next_type: false,
+                    });
+                    return true;
+                } else {


This else condition is unnecessary since the if returns.

GuillaumeGomez · 2017-11-12T20:20:53Z

src/analysis/bounds.rs

@@ -196,18 +236,20 @@ impl Bounds {
    pub fn get_parameter_alias_info(&self, name: &str) -> Option<(char, BoundType)> {
        self.used
            .iter()
-            .find(move |n| if n.parameter_name == name {
+            .find(move |n| {
+                if n.parameter_name == name {
                !n.info_for_next_type


The indent is broken in here. :p

GuillaumeGomez · 2017-11-12T20:21:33Z

src/analysis/function_parameters.rs

        };

+        if async_func {


if async_func && async_param_to_remove(&par.name) { add_rust_parameter = false; }

GuillaumeGomez · 2017-11-12T20:22:51Z

src/analysis/rust_type.rs

 ) -> Result {
    use library::Type::*;
    let type_ = env.library.type_(type_id);
    let rust_type = rust_type_full(env, type_id, nullable, ref_mode);
    match *type_ {
+        Fundamental(super::library::Fundamental::Pointer) if async => Ok("TODO4".to_string()), // FIXME: remove


Yeah, some TODO that are not generated.
I'll have to figure out why.

GuillaumeGomez · 2017-11-12T20:24:38Z

What I'm seeing for the moment seems correct (even if it seems incomplete). However I'm not the maintainer in here hehe.

sdroege · 2017-11-12T22:51:02Z

Can you create a PR for gio with the changes this would add, i.e. all the implementations for the async methods in GFile?

EPashkin · 2017-11-13T03:41:58Z

src/codegen/function_body_chunk.rs

+                .map(|param| (param, type_mem_mode(env, param)))
+                .map(|(param, mode)| format!("let mut {} = {};\n", param.name, mode_to_string(mode)))
+                .collect::<Vec<_>>()
+                .join("                ");


Please change it to "\t\t\t\t"

I'll instead change that to use Chunk directly, to avoid having code as strings.

EPashkin · 2017-11-13T03:45:04Z

src/codegen/function_body_chunk.rs

+                        Ok(({result}))
+                    }} else {{
+                        Err(from_glib_full(error))
+                    }};


IMHO let result = better be oneliner.

EPashkin · 2017-11-13T03:51:05Z

src/codegen/function_body_chunk.rs

+    if id == namespaces::MAIN {
+        return "ffi".to_string();
+    }
+    format!("{}_ffi", name)


Namespace.ffi_crate_name is not same?

ffi_crate_name is only available on the other Namespace struct.

EPashkin · 2017-11-13T04:00:29Z

@antoyo Overall is good idea, I slightly not like "internal trampoline" but it not so big problem. Thanks.

antoyo · 2017-11-13T13:10:37Z

@sdroege I'll do it when I get back to Canada, so maybe in one week.
@EPashkin I didn't know how to do it (not sure if I can reuse the trampoline logic), so I did it this way because I wanted to have something working during the HackFest.
But the overall trampoline code generation should be redone before we merge this PR.

Thanks to all of you for your comments.

EPashkin · 2017-11-13T15:58:34Z

@antoyo don't worry about trampolines.

antoyo · 2017-11-22T23:29:07Z

@sdroege Here's the PR.

antoyo · 2017-11-23T04:30:25Z

I've fixed all the issues you mentioned and I've fixed the async trampoline code generation.
I think this PR is ready to be tested.
Do we have any infrastructure to test gir against every GNOME library that we support?

EPashkin · 2017-11-23T04:42:22Z

@antoyo No we don't have :(
I tested building of examples on updated gtk, it builds fine.

EPashkin · 2017-11-23T04:45:55Z

@GuillaumeGomez we add async function it this release?

sdroege · 2017-11-23T08:01:39Z

I added some comments about the generated code here gtk-rs/gio#63

sdroege · 2017-11-25T12:16:21Z

IMHO this is good to go, judging from the generated code.

GuillaumeGomez · 2017-11-25T12:24:46Z

Seems good to me as well. Is it good for you @EPashkin or do you want to add something else @antoyo?

EPashkin · 2017-11-25T14:11:16Z

@GuillaumeGomez Its good for me too.
You wan't add this before release?

GuillaumeGomez · 2017-11-25T15:35:55Z

Yes if possible so I'll handle the release tomorrow as the latest (won't be able to do it before next week-end otherwise).

antoyo · 2017-11-25T16:00:18Z

@sdroege @GuillaumeGomez I wanted to fix the Cancellable issue mentionned by @sdroege.
I think I can do it today.

antoyo · 2017-11-25T17:30:29Z

This will require to add Gio.Cancellable in Gir.toml files when needed.
I'll commit the fix soon.

EPashkin · 2017-11-25T18:33:53Z

Gtk-rs examples still builds.
@sdroege, @antoyo there still any problem? Or I can merge?

GuillaumeGomez · 2017-11-25T18:35:13Z

For me it was already good so as you wish!

antoyo · 2017-11-25T18:35:48Z

It's ready to be merged.
Just waiting for @sdroege to see the latest change (&&Fn).

sdroege · 2017-11-25T19:02:43Z

See my comment there

antoyo · 2017-11-25T20:24:50Z

I've fixed this issue in the latest commit.

antoyo · 2017-11-25T22:40:25Z

@sdroege I've fixed the other issues mentionned in the gio PR.

EPashkin · 2017-11-26T04:13:29Z

@antoyo Thanks.
I add regen PR for sourceview. Gtk, glib has only commented changes and IMHO can be ignored.

EPashkin · 2017-11-26T04:48:50Z

Actually gtk also have async functions in IconInfo, but current version not works good outside gio as it don't add use gio_ffi

EPashkin · 2017-11-26T05:05:37Z

Created fix, will add regen for Gtk too.

sdroege · 2017-11-26T09:00:58Z

Looks good to me, just need to add support for the "progress-callback" pattern in the future, as used by various async operations

Add async method code generation

Add async method code generation

dcc04f6

GuillaumeGomez reviewed Nov 12, 2017

View reviewed changes

EPashkin reviewed Nov 13, 2017

View reviewed changes

antoyo added 3 commits November 22, 2017 20:33

Fix style and tests

11ef7fd

Cleanup

114440f

Improve async trampoline code generation

18053b1

antoyo mentioned this pull request Nov 23, 2017

Async code generation gtk-rs/gio#63

Merged

Fix for Cancellable and &&Fn

f71e698

Fix Box<Box> to add Send + Sync

9e87ba8

Fix for RefRef and add 'static

dc0152c

EPashkin merged commit 24099bb into gtk-rs:master Nov 26, 2017

EPashkin mentioned this pull request Nov 26, 2017

Regen gtk-rs/sourceview#25

Merged

EPashkin mentioned this pull request Nov 26, 2017

Add use gio_ffi if needed #493

Merged

EPashkin mentioned this pull request Nov 26, 2017

Regen gtk-rs/gtk#594

Merged

EPashkin mentioned this pull request Nov 26, 2017

Add callback_guard to async trampolines #494

Merged

vhdirk pushed a commit to vhdirk/gir that referenced this pull request Jul 6, 2018

Merge pull request gtk-rs#490 from antoyo/feature/async-method

939f6c4

Add async method code generation

Uh oh!

Add async method code generation #490

Add async method code generation #490

Uh oh!

Conversation

antoyo commented Nov 12, 2017

Uh oh!

antoyo commented Nov 12, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GuillaumeGomez commented Nov 12, 2017

Uh oh!

sdroege commented Nov 12, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

EPashkin commented Nov 13, 2017

Uh oh!

antoyo commented Nov 13, 2017

Uh oh!

EPashkin commented Nov 13, 2017

Uh oh!

antoyo commented Nov 22, 2017

Uh oh!

antoyo commented Nov 23, 2017

Uh oh!

EPashkin commented Nov 23, 2017

Uh oh!

EPashkin commented Nov 23, 2017

Uh oh!

sdroege commented Nov 23, 2017

Uh oh!

sdroege commented Nov 25, 2017

Uh oh!

GuillaumeGomez commented Nov 25, 2017

Uh oh!

EPashkin commented Nov 25, 2017

Uh oh!

GuillaumeGomez commented Nov 25, 2017

Uh oh!

antoyo commented Nov 25, 2017

Uh oh!

antoyo commented Nov 25, 2017

Uh oh!

EPashkin commented Nov 25, 2017

Uh oh!

GuillaumeGomez commented Nov 25, 2017

Uh oh!

antoyo commented Nov 25, 2017

Uh oh!

sdroege commented Nov 25, 2017

Uh oh!

antoyo commented Nov 25, 2017

Uh oh!

antoyo commented Nov 25, 2017

Uh oh!

EPashkin commented Nov 26, 2017

Uh oh!

EPashkin commented Nov 26, 2017

Uh oh!

EPashkin commented Nov 26, 2017