Weird dropck errors when making a change that does not seemingly affect the public API

[sfackler]

I unfortunately haven't had a chance to minimize this, but here's the diff that both runs into the issue and fixes the dropck issues: sfackler/rust-postgres@18e61b3

An example of one of the complaints:

tests/types/mod.rs:215:16: 215:20 error: `conn` does not live long enough
tests/types/mod.rs:215     let stmt = conn.prepare("SELECT * FROM foo WHERE id = ANY($1)").unwrap();
                                      ^~~~
tests/types/mod.rs:211:28: 221:2 note: reference must be valid for the destruction scope surrounding block at 211:27...
tests/types/mod.rs:211 fn test_slice_wrong_type() {
tests/types/mod.rs:212     let conn = Connection::connect("postgres://postgres@localhost", &SslMode::None).unwrap();
tests/types/mod.rs:213     conn.batch_execute("CREATE TEMPORARY TABLE foo (id SERIAL PRIMARY KEY)").unwrap();
tests/types/mod.rs:214 
tests/types/mod.rs:215     let stmt = conn.prepare("SELECT * FROM foo WHERE id = ANY($1)").unwrap();
tests/types/mod.rs:216     match stmt.query(&[&Slice(&["hi"])]) {
                       ...
tests/types/mod.rs:212:94: 221:2 note: ...but borrowed value is only valid for the block suffix following statement 0 at 212:93
tests/types/mod.rs:212     let conn = Connection::connect("postgres://postgres@localhost", &SslMode::None).unwrap();
tests/types/mod.rs:213     conn.batch_execute("CREATE TEMPORARY TABLE foo (id SERIAL PRIMARY KEY)").unwrap();
tests/types/mod.rs:214 
tests/types/mod.rs:215     let stmt = conn.prepare("SELECT * FROM foo WHERE id = ANY($1)").unwrap();
tests/types/mod.rs:216     match stmt.query(&[&Slice(&["hi"])]) {
tests/types/mod.rs:217         Ok(_) => panic!("Unexpected success"),
                       ...

It looks like the lifetime of the temporary defined in the match argument is suddenly being extended? It's not totally clear to me what's going on here. Any ideas @pnkfelix?

[sfackler]

Ah, Statement implements Drop, so it could be that this is caused by StatementContainer gaining a destructor. This might be known but suboptimal behavior then?

[arielb1]

It's quite simple: destroying the StatementContainer can destroy the contained Statement, so it needs the Connection to be alive, but temporaries in a tail expression are destroyed after local variables, so the result of query would be destroyed after conn is. Unfortunate, but not a bug, and not dropck's fault.