Skip to content
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

Resolve some todos in async-await branch #452

Merged
merged 53 commits into from
Nov 7, 2019
Merged

Resolve some todos in async-await branch #452

merged 53 commits into from
Nov 7, 2019

Conversation

nWacky
Copy link
Contributor

@nWacky nWacky commented Nov 4, 2019

This PR resolves some todos in async-await branch.

Changelog:

  • Resolve RFC 2565 related todos
  • Remove __juniper_extract_generic macro
  • Add resolve_into_type_async to GraphQLTypeAsync for asynchronous fragments resolving
  • Update GraphQLTypeAsync with async-trait, update macros
  • Resolve "better error message with field/type name" todo, update other panics with query name (query name retrieved by calling self::name(info))
  • Rebase onto master
  • Format

Copy link
Member

@LegNeato LegNeato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks again for so much work! Some small tweaks / questions. Also, can you rebase on async-await again?

juniper_warp = { git = "https:/graphql-rust/juniper", branch = "async-await", features = ["async"] }
#juniper_codegen = { git = "https:/graphql-rust/juniper", branch = "async-await", features = ["async"] }
#juniper = { git = "https:/graphql-rust/juniper", branch = "async-await", features = ["async"] }
#juniper_warp = { git = "https:/graphql-rust/juniper", branch = "async-await", features = ["async"] }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Remove these

// #[doc = "and more details"]
// arg: i32,
// ) -> i32 { 0 }
fn attr_arg_descr(arg: i32) -> i32 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks wrong? Also, we have #441 outstanding

Copy link
Contributor Author

@nWacky nWacky Nov 5, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it.
I put it back to todos until #441 is resolved

}
enum ResolversWithTrailingComma {
Concrete(Concrete),
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why were these added back?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, my mistake

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this fixed? Is this a bad merge?

@nWacky nWacky requested a review from LegNeato November 5, 2019 16:30
@@ -234,6 +234,8 @@ fn test_introspection_possible_types() {
assert_eq!(possible_types, vec!["Human", "Droid"].into_iter().collect());
}

/*
* FIXME: make this work again
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something is wonky with the merge or you haven't rebased on latest async-await as this undoes a change we want.

@@ -95,13 +95,16 @@ impl Root {
Ok(0)
}

/*
* FIXME: make this work again
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like you need to rebase or a bad merge?

}
enum ResolversWithTrailingComma {
Concrete(Concrete),
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this fixed? Is this a bad merge?

Copy link
Member

@LegNeato LegNeato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm seeing some weirdness where stuff in the async-await branch is undone. Not sure if you just need to rebase or there is something else going on.

@nWacky
Copy link
Contributor Author

nWacky commented Nov 6, 2019

Yes, git messed everything up while merging. Sorry for that.
Now everything should be good

@LegNeato LegNeato merged commit b133a0f into graphql-rust:async-await Nov 7, 2019
@tyranron tyranron deleted the async-await-resolve-some-todos branch November 7, 2019 06:40
@theduke
Copy link
Member

theduke commented Nov 13, 2019

I'm sorry I didn't see this before, but I'm not actually on board with using async-trait.

It's a nice library, but it just adds a bit of syntax sugar, and it very well might differ from the semantics of compiler support, which isn't on the near-horizon. Also 99% of the code will be auto-generated by the macros, so we want to avoid that extra dependency.

@theduke
Copy link
Member

theduke commented Nov 13, 2019

Could you handle reverting, @nWacky ?

@nWacky
Copy link
Contributor Author

nWacky commented Nov 13, 2019

@theduke

Yes, I'll remove async-trait today. Juniper's macros don't depend on async-trait, I wrote all lifetimes by hand

@theduke
Copy link
Member

theduke commented Nov 13, 2019

Thanks. I think we will want to merge the async branch in the next few days to avoid extra churn.

I also have some bigger refactorings upcoming that would affect subscriptions, we might want to chat about that on Gitter or somewhere.

@nWacky
Copy link
Contributor Author

nWacky commented Nov 13, 2019

Yeah, that would be great

@LegNeato
Copy link
Member

@theduke I converted a project at work to async_trait and it made the implementations much more readable as everything didn't have to have Box and Pin everywhere. It also let me clean up some futures::future::Either use as well. But I guess I don't feel strongly enough to keep it.

@theduke
Copy link
Member

theduke commented Nov 14, 2019

I have a type system change which gets rid of GraphlQLTypeAsync that makes this impossible.

Not 100% sure yet if it will work out, but if it does it should be ready soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants