Skip to content

juniper::object generated code scope is not isolated #465

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

Closed
ghost opened this issue Nov 22, 2019 · 2 comments
Closed

juniper::object generated code scope is not isolated #465

ghost opened this issue Nov 22, 2019 · 2 comments
Labels
enhancement Improvement of existing features or bugfix

Comments

@ghost
Copy link

ghost commented Nov 22, 2019

juniper::object() macro generates a lambda that has access to the rest of the scope. This is unsafe since the user can access any symbol of the code when juniper::object() expands.
This is the code I am talking about:

let resolver_code = quote!(
(|| #return_ty {
#( #resolve_parts )*
#body
})()
);

It would be better to define a fn and give it the needed arguments.

@ghost ghost added the enhancement Improvement of existing features or bugfix label Nov 22, 2019
@ghost ghost changed the title juniper::object() macro is unsafe juniper::object() macro is unsafe Nov 22, 2019
@theduke theduke changed the title juniper::object() macro is unsafe juniper::object generated code scope is not isolated Nov 22, 2019
@theduke
Copy link
Member

theduke commented Nov 22, 2019

Unsafe has a specific meaning in Rust, and is not appropriate here. This is not related to memory unsafety.

Also, there isn't anything in scope that you couldn't get access to by specifying it; just the executor and arguments. You can also request the executor, just like the context, by specifying it as an argument.

It is admittedly unclean though and unexpected to magically have variables in scope. I have wanted to rewrite it to a regular function definition before, and we will get around to that soon, hopefully. It's a relatively small change.

@tyranron
Copy link
Member

Fixed in #971

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvement of existing features or bugfix
Projects
None yet
Development

No branches or pull requests

2 participants