I am using rust sqlx and I am getting a connection from my DB pool for my query:
POOL: OnceCell<Pool<Postgres>> = OnceCell::new();
pub async fn get_connection() -> PoolConnection<Postgres> {
POOL.get().unwrap().acquire().await.unwrap()
}
pub async fn fetch_users() -> Result<Vec<User>> {
let result = sqlx::query_as!(User,
r#"SELECT * FROM users"#)
.fetch_all(get_connection().await).await?;
Ok(result)
}
But get_connection().await is giving me an error:
the trait bound `sqlx::pool::PoolConnection<sqlx::Postgres>: sqlx::Executor<'_>` is not satisfied expected an implementor of trait `sqlx::Executor<'_>`
The compiler is telling me to fix by using consider mutably borrowing here: `&mut` which works fine when I change to &mut get_connection().await.
I don't understand why this fixes the issue. Can anyone explain?
Looking at the implementations for sqlx::Executor, all of them are on some &mut T type. It is implemented for &mut PoolConnection<Postgres> but not PoolConnection<Postgres>.
Adding &mut changes it from passing a PoolConnection<Postgres> into a &mut PoolConnection<Postgres>. This is required since Rust does not auto-borrow function parameters.
Related
I seem to have a basic problem that I can't solve.
I have this struct that expects apinned dynamic writer to pass to "C" and then later gets it back as a part of a callback function:
Here is the struct:
pub struct ExecutionContext<'a> {
pub log: Pin<&'a mut Box<dyn std::io::Write>>,
}
I can't seem to find a way to pass a simple stderr to this struct though.
If I try
let mut stderr2 = Pin::new (&mut Box::<dyn Write>::new(stderr()));
I get this error:
function or associated item cannot be called on `Box<dyn std::io::Write>` due to unsatisfied trait bounds
When I try this:
let mut stderr2 = Pin::new (&mut Box::new(stderr()));
let mut ctx = ExecutionContext{
log: stderr2,
};
I get :
expected trait object `dyn std::io::Write`, found struct `Stderr`
The first error continues with:
the following trait bounds were not satisfied: dyn std::io::Write: Sized
The problem is that somehow calling Box::new with this type bounds requires the inner value of the Box to have a known size. Trait objects cannot provide that.
You can avoid that by creating explicitly a variable with your type annotations.
let mut b: Box<dyn Write> = Box::new(stderr());
let stderr2 = Pin::new(&mut b);
let mut ctx = ExecutionContext { log: stderr2 };
playground
But may I ask for the reason of putting a Box behind a mutable reference?
Isn't a Box enough?
If you are willing to change the type of ExecutionContext::log I would recommend the following:
store the Box directly behind the Pin in ExecutionContext::log (without the reference)
use Box::pin, a constructor which creates a Pin<Box<T>> for you
pub struct ExecutionContext {
pub log: Pin<Box<dyn std::io::Write>>,
}
let stderr2 = Box::pin(stderr());
let mut ctx = ExecutionContext { log: stderr2 };
playground
I've worked down a real-life example in a web app, which I've solved using unnecessary heap allocation, to the following example:
// Try replacing with (_: &String)
fn make_debug<T>(_: T) -> impl std::fmt::Debug {
42u8
}
fn test() -> impl std::fmt::Debug {
let value = "value".to_string();
// try removing the ampersand to get this to compile
make_debug(&value)
}
pub fn main() {
println!("{:?}", test());
}
As is, compiling this code gives me:
error[E0597]: `value` does not live long enough
--> src/main.rs:9:16
|
5 | fn test() -> impl std::fmt::Debug {
| -------------------- opaque type requires that `value` is borrowed for `'static`
...
9 | make_debug(&value)
| ^^^^^^ borrowed value does not live long enough
10 | }
| - `value` dropped here while still borrowed
I can fix this error in at least two ways:
Instead of passing in a reference to value in test(), pass in value itself
Instead of the parameter T, explicitly state the type of the argument for make_debug as &String or &str
My understanding of what's happening is that, when there is a parameter, the borrow checker is assuming that any lifetime on that parameter affects the output impl Debug value.
Is there a way to keep the code parameterized, continue passing in a reference, and get the borrow checker to accept it?
I think this is due to the rules around how impl trait opaque types capture lifetimes.
If there are lifetimes inside an argument T, then an impl trait has to incorporate them. Additional lifetimes in the type signature follow the normal rules.
For more information please see:
https://github.com/rust-lang/rust/issues/43396#issuecomment-349716967
https://github.com/rust-lang/rfcs/blob/master/text/1951-expand-impl-trait.md#lifetime-parameters
https://github.com/rust-lang/rfcs/blob/master/text/1951-expand-impl-trait.md#assumption-3-there-should-be-an-explicit-marker-when-a-lifetime-could-be-embedded-in-a-return-type
https://github.com/rust-lang/rfcs/blob/master/text/1951-expand-impl-trait.md#scoping-for-type-and-lifetime-parameters
A more complete answer
Original goal: the send_form function takes an input parameter of type &T which is rendered to a binary representation. That binary representation is owned by the resulting impl Future, and no remnant of the original &T remains. Therefore, the lifetime of &T need not outlive the impl Trait. All good.
The problem arises when T itself, additionally, contains references with lifetimes. If we were not using impl Trait, our signature would look something like this:
fn send_form<T>(self, data: &T) -> SendFormFuture;
And by looking at SendFormFuture, we can readily observe that there is no remnant of T in there at all. Therefore, even if T has lifetimes of its own to deal with, we know that all references are used within the body of send_form, and never used again afterward by SendFormFuture.
However, with impl Future as the output, we get no such guarantees. There's no way to know if the concrete implementation of Future in fact holds onto the T.
In the case where T has no references, this still isn't a problem. Either the impl Future references the T, and fully takes ownership of it, or it doesn't reference it, and no lifetime issues arise.
However, if T does have references, you could end up in a situation where the concrete impl Future is holding onto a reference stored in the T. Even though the impl Future has ownership of the T itself, it doesn't have ownership of the values referenced by the T.
This is why the borrow check must be conservative, and insist that any references inside T must have a 'static lifetime.
The only workaround I can see is to bypass impl Future and be explicit in the return type. Then, you can demonstrate to the borrow checker quite easily that the output type does not reference the input T type at all, and any references in it are irrelevant.
The original code in the actix web client for send_form looks like:
https://docs.rs/awc/0.2.1/src/awc/request.rs.html#503-522
pub fn send_form<T: Serialize>(
self,
value: &T,
) -> impl Future<
Item = ClientResponse<impl Stream<Item = Bytes, Error = PayloadError>>,
Error = SendRequestError,
> {
let body = match serde_urlencoded::to_string(value) {
Ok(body) => body,
Err(e) => return Either::A(err(Error::from(e).into())),
};
// set content-type
let slf = self.set_header_if_none(
header::CONTENT_TYPE,
"application/x-www-form-urlencoded",
);
Either::B(slf.send_body(Body::Bytes(Bytes::from(body))))
}
You may need to patch the library or write your own function that does the same thing but with a concrete type. If anyone else knows how to deal with this apparent limitation of impl trait I'd love to hear it.
Here's how far I've gotten on a rewrite of send_form in awc (the actix-web client library):
pub fn send_form_alt<T: Serialize>(
self,
value: &T,
// ) -> impl Future<
// Item = ClientResponse<impl Stream<Item = Bytes, Error = PayloadError>>,
// Error = SendRequestError,
) -> Either<
FutureResult<String, actix_http::error::Error>,
impl Future<
Item = crate::response::ClientResponse<impl futures::stream::Stream>,
Error = SendRequestError,
>,
> {
Some caveats so far:
Either::B is necessarily an opaque impl trait of Future.
The first param of FutureResult might actually be Void or whatever the Void equivalent in Rust is called.
While developing on a private project I ran into a lifetime problem related to borrowing the same object over multiple structs and traits. This is a bunch of stripped-down definitions I used:
trait WorkspaceLog {
fn get(&self) -> usize;
}
struct TheLog<'a>(&'a FilesystemOverlay);
impl<'a> WorkspaceLog for TheLog<'a> {
fn get(&self) -> usize {
(self.0).0
}
}
trait WorkspaceController<'a> {
type Log: WorkspaceLog;
fn get_log(&'a self) -> Self::Log;
}
struct FilesystemOverlay(usize);
struct FSWorkspaceController<'a>(&'a mut FilesystemOverlay);
impl<'a> WorkspaceController<'a> for FSWorkspaceController<'a> {
type Log = TheLog<'a>;
fn get_log(&'a self) -> Self::Log {
TheLog(&*self.0)
}
}
trait AsWorkspaceController<'a> {
type Controller: WorkspaceController<'a>;
fn get_controller(self) -> Self::Controller;
}
impl<'a> AsWorkspaceController<'a> for &'a mut FilesystemOverlay {
type Controller = FSWorkspaceController<'a>;
fn get_controller(self) -> FSWorkspaceController<'a> {
FSWorkspaceController(self)
}
}
So far, so good. This basically enables me to borrow a mut ref of FilesystemOverlay as some other interface, providing additional functionality. This interface, in turn, allows me to borrow essentially the same thing as yet another thing that provides the final data. This works as long a I directly use FilesystemOverlay:
fn init1(control_dir: &mut FilesystemOverlay) -> usize {
let controller = control_dir.get_controller();
let log = controller.get_log();
log.get()
}
However, if I replace the concrete reference with a type parameter, the compilation fails, telling me that controller doesn't live long enough since it, for reasons I don't understand, thinks that get_log borrows controller beyond the end of the function and thus way longer than the program logic
requires:
fn init2<'a: 'b, 'b, O>(control_dir: O) -> usize
where O: AsWorkspaceController<'b>+'a {
let controller = control_dir.get_controller();
let log = controller.get_log();
log.get()
}
fn main() {
let mut control_dir = FilesystemOverlay(5);
dbg!(init1(&mut control_dir));
dbg!(init2(&mut control_dir));
}
I tried several approaches but I so far were unable to figure out the proper signature of init2. This is the error I get:
error[E0597]: `controller` does not live long enough
--> test.rs:53:15
|
53 | let log = controller.get_log();
| ^^^^^^^^^^ borrowed value does not live long enough
54 | log.get()
55 | }
| - borrowed value only lives until here
|
note: borrowed value must be valid for the lifetime 'b as defined on the function body at 50:18...
--> test.rs:50:18
|
50 | fn init2<'a: 'b, 'b, O>(control_dir: O) -> usize
| ^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0597`.
This is the full code on the rust playground.
So, how do I need to change the signature of init2 so that the compiler understands that controller may be dropped after the call to log.get()? Do I need other changes in the above types as well?
Edit: I've made some additional experiments and this is the closest I could manage to create. This one has two lifetimes and a signature that late-binds, but it still gives a warning about UB. Does anyone understand why?
With the help of a nice and knowing person on GitHub I was able to create a working version of the code, see https://github.com/rust-lang/rust/issues/58868. The key was to use a free lifetime bound on the type declaration of Controller inside AsWorkspaceController:
trait AsWorkspaceController<'a> {
type Controller: for<'b> WorkspaceController<'b>+'a;
fn get_controller(&'a mut self) -> Self::Controller;
}
See the full code on the playground.
I am trying to write a function returning a boxed closure that can work on references to types with any
lifetime. When writing a specific instance, everything works fine. But when writing a generic
version, I run into lifetime problems.
struct Parameter<'a> {
s: &'a str,
}
fn main() {
let closure = generate_closure_gen();
let string = String::from("Hello World!");
let parameter = Parameter { s: &string }; // Error: string does not live long enough
closure(¶meter);
}
// This one works fine
// Desugared version for Box<Fn(&Parameter)>
fn generate_closure() -> Box<for <'a, 'r> Fn(&'r Parameter<'a>)> {
Box::new(|c: &Parameter| {})
}
// This one gives lifetime errors
fn generate_closure_gen<C>() -> Box<Fn(&C)> {
Box::new(|c: &C| {})
}
I don't see why the closure needs the type parameter to live longer than it (there is no storage or anything ...). And it works for the non-generic version with HRTB, it just feels like it should be possible to make it work with the generic version.
Also, if I try to write the specific version using the generic version, I get a type error
// Desugared version for Box<Fn(&Parameter)>
fn generate_closure_2() -> Box<for <'a, 'r> Fn(&'r Parameter<'a>)> {
generate_closure_gen()
}
src/main.rs:22:5: 22:27 error: mismatched types:
expected `Box<for<'r, 'r> core::ops::Fn(&'r Parameter<'r>) + 'static>`,
found `Box<for<'r> core::ops::Fn(&'r _) + 'static>`
(expected concrete lifetime,
found bound lifetime parameter ) [E0308]
src/main.rs:22 generate_closure_gen()
^~~~~~~~~~~~~~~~~~~~~~
src/main.rs:22:5: 22:27 help: run `rustc --explain E0308` to see a detailed explanation
Any idea on how to make this work?
(playpen link)
Type parameters have a lifetime bound. That lifetime bound is the shortest of all of the implementor's lifetime parameters. You omitted it on generate_closure_gen, so the compiler inferred it, but if we explicitly wrote it out, the function definition would look like this:
fn generate_closure_gen<'a, C: 'a>() -> Box<Fn(&C)> {
Box::new(|c: &C| {})
}
Making this change doesn't solve our problem, though.
To understand why, we need to figure out what C is inferred to be. You call the closure with a &'y Parameter<'x>, and the closure accepts for<'b> &'b C, so C is Parameter<'x>. Parameter<'x> has a lifetime parameter, which will have an influence on the lifetime bound on C.
Lifetime parameters in generic functions must be substituted with lifetimes that start before the function call. In this case, this means that the lifetime of any C we pass to the closure must be valid before the call to generate_closure_gen. That's because C is bound to a specific lifetime, not to any lifetime; i.e. when C is Parameter<'x>, the 'x must be known in advance; we can't have a different 'x each time we call the closure. In other words, what you'd like to have is something like this:
fn generate_closure_gen<C: for<'a> 'a>() -> Box<Fn(&C)> {
Box::new(|c| {})
}
But unfortunately, that isn't legal as of Rust 1.7.
I have this small Rust function:
pub fn factor(input_array: &mut [i32]) {
let x = input_array
.iter()
.filter(|&x| x % 2 == 0);
x
}
When I run this via cargo run I get this error:
Compiling gettingrusty v0.0.1 (file:///home/lowks/src/rust/gettingrusty)
src/functional.rs:22:9: 22:10 error: mismatched types:
expected `()`,
found `core::iter::Filter<core::slice::Iter<'_, i32>, [closure#src/functional.rs:21:21: 21:36]>`
(expected (),
found struct `core::iter::Filter`) [E0308]
src/functional.rs:22 x
^
src/functional.rs:22:9: 22:10 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to previous error
Could not compile `gettingrusty`.
I tried a few return types such as slice::Iter<i32> and core::slice::Iter<i32> but seems like all of them are wrong. What should be the return type of my function?
Under normal circumstances, you could just copy+paste the found part of the error message. There are two problems with that in this particular case.
First, core isn't directly accessible. Various items are exposed by the standard library libstd, but are actually defined by libcore. Basically, the standard library is the public interface you are meant to use to access these items, but the compiler doesn't know that. Typically, you work around this by just replacing core::* with std::*.
The second problem is that the type includes a closure, and closures cannot be named. The simplest solution is to just not use a closure at all; you aren't capturing anything, anyway.
Doing that and just fixing the compile errors as they come up leads to:
pub fn factor(input_array: &mut [i32])
-> std::iter::Filter<std::slice::Iter<i32>, fn(&&i32) -> bool> {
fn even(x: &&i32) -> bool { **x % 2 == 0 }
let x = input_array
.iter()
.filter(even as for<'r> fn(&'r &_) -> _);
x
}
Your function returns a Filter object, so its actual return type is Filter<_, _> for some generic arguments. That’s fine, but chances are, you’ll want to hide all the implementation details from the type signature and just say that your function returns some iterator. Unfortunately, there is no (as of today) easy way to do this.
The pattern that seems to be rather common is to use a newtype wrapper. The problem with this is that writing the wrapper is a little bit more difficult than one might expect, e.g. one will have to deal with lifetimes explicitly.
Here is a complete example:
use std::iter::Filter;
use std::slice::Iter;
struct FactorResult<'a, T: 'a>(Filter<Iter<'a, T>, fn(&&T) -> bool>);
impl<'a, T> Iterator for FactorResult<'a, T> {
type Item = &'a T;
fn next(&mut self) -> Option<&'a T> { self.0.next() }
fn size_hint(&self) -> (usize, Option<usize>) { self.0.size_hint() }
}
fn factor(input_array: &[i32]) -> FactorResult<i32> {
fn even(x : &&i32) -> bool { **x % 2 == 0 }
FactorResult(input_array.iter().filter(even))
}
fn main () {
for x in factor(&[1,2,3,4]) {
println!("{}", x);
}
}
The factor function returns a FactorResult which is just a wrapper that hides the actual underlying type.
The only thing the user knows about FactorResult is that it is an Iterator. The implementation of the trait is trivial, but I had to spell it out.
I had to replace the closure with the function. This is because here Rust does not perform any allocations, so it needs to know the size of FactorResult<T>, but the type of the closure is anonymous so there is no way to refer to it. One could use a closure but the whole thing would have to be boxed in this case.