Repository navigation
Description
Hi! I'm trying to compile my Rocket/Diesel/R2d2 task management project, which has previously successfully compiled, and when I add the newest piece which relies on macros in some new/different way (sorry for vague, I'm new to rust) it starts failing to compile.
Looking at the backtrace, the error seems to be in MacroExpander::expand_invoc.
new code that causes the bug
#[post("ctl"), format="application/json", data=nt]
fn append_ctl_struct(conn: DbConn, nt: NewTask) -> &'static str {
use schema::ctl::dsl::*;
diesel::insert_into(ctl)
.values(&nt)
.get_result::<Task>(&*conn);
return "Struckt Bites."
}
expected behavior:
I expect it to have the same behavior as the simpler version of the route:
#[post("/ctl/<tsk>/<disc>")]
fn append_ctl(conn: DbConn, tsk: String, disc: bool) -> &'static str {
use schema::ctl::dsl::*;
let nt = NewTask{
name: &tsk,
discrete: disc
};
diesel::insert_into(ctl)
.values(&nt)
.get_result::<Task>(&*conn);
// .expect("failed to insert task to CTL")
return "Bagel Bites."
}
which warns about unused query result on compile but successfully runs, builds the NewTask struct from url components, and inserts it into the database.
result behavior
it fails to compile during cargo run, and the same exact error shows during cargo check. I've pasted the whole command with outputs here:
https://gist.github.com/haniawni/d333080a91c0370de6a245713f803c84
replication
Check out my project's "uhoh" branch for the exact code where I get the bug.
Check out my project's master branch at commit 5ec317 to see the functional version (requires a local postgresql instance and a DATABASE_URL env variable in a env file).
Activity
estebank commentedon Mar 11, 2018
ExpHP commentedon Mar 12, 2018
looks familiar...
ExpHP commentedon Mar 12, 2018
I minimized
rocket_codegendown to nothing but 14 looping macros in order to squarely place the blame on a single culprit once and for all:https://github.com/ExpHP/Rocket-issue-48387
A function that just loops surely cannot be responsible for dropping a
DiagnosticBuilder, so theError constructed but not emittedmust be a bug in rustc.(I still rather doubt it is in
expand_invocthough, but rather, in a function that gets inlined into it)ExpHP commentedon Mar 13, 2018
So...
I mentioned in the other issue how terrifying of a concept I thought
PResultwas.For the uninitiated,
PResultis a type alias for aResultwith aDiagnosticBuilderin itsErrvariant, which acts like a ticking timebomb; it explodes if the error is ever dropped. Simply put,Resulthas some methods that you must never call on aPResult.rust/src/libsyntax/ext/expand.rs
Lines 486 to 490 in 883e746
Do you see it? 😉
estebank commentedon Mar 13, 2018
Ha! Thank you for the digging @ExpHP. That stray
.ok()is really cheeky, ain't it?ExpHP commentedon Mar 13, 2018
I'll probably submit a PR; I'm just browsing around the existing test cases for plugins trying to glean "best practices."
(I'm also trying to see if there's any test case that causes the other
ok()in theMultiDecorator(ref mac)branch to blow up. I don't think there is since it appears that the full#[derive]attribute gets parsed before it tries to expandderive_FromForm.)Rollup merge of rust-lang#48990 - ExpHP:dont-drop-the-bomb, r=estebank