Panic during compiling/checking; maybe Rocket/Diesel/R2d2 macro use?

[haniawni]

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).

[estebank]

     Running `rustc --crate-name get_stuff_done src/main.rs --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=57f9cdfec93028f0 -C extra-filename=-57f9cdfec93028f0 --out-dir /Users/reembodied/Documents/workplace/GSD/target/debug/deps -C incremental=/Users/reembodied/Documents/workplace/GSD/target/debug/incremental -L dependency=/Users/reembodied/Documents/workplace/GSD/target/debug/deps --extern r2d2=/Users/reembodied/Documents/workplace/GSD/target/debug/deps/libr2d2-5ee46b683767f62a.rlib --extern dotenv=/Users/reembodied/Documents/workplace/GSD/target/debug/deps/libdotenv-11d6c368f55e51dc.rlib --extern serde_json=/Users/reembodied/Documents/workplace/GSD/target/debug/deps/libserde_json-4d2498fc1773ad64.rlib --extern serde=/Users/reembodied/Documents/workplace/GSD/target/debug/deps/libserde-a870014ba779aecf.rlib --extern rocket_contrib=/Users/reembodied/Documents/workplace/GSD/target/debug/deps/librocket_contrib-c91514945a0602e5.rlib --extern rocket=/Users/reembodied/Documents/workplace/GSD/target/debug/deps/librocket-fa1e8f79ed259746.rlib --extern diesel=/Users/reembodied/Documents/workplace/GSD/target/debug/deps/libdiesel-c5fe6a028fa90bc3.rlib --extern rocket_codegen=/Users/reembodied/Documents/workplace/GSD/target/debug/deps/librocket_codegen-e22163b7f02193ea.dylib --extern chrono=/Users/reembodied/Documents/workplace/GSD/target/debug/deps/libchrono-01e8ade0bcc6f635.rlib --extern serde_derive=/Users/reembodied/Documents/workplace/GSD/target/debug/deps/libserde_derive-fe1669d5f547364d.dylib --extern r2d2_diesel=/Users/reembodied/Documents/workplace/GSD/target/debug/deps/libr2d2_diesel-3f90588d0f23df53.rlib -L native=/Users/reembodied/Documents/workplace/GSD/target/debug/build/ring-917da51119e12995/out`
error: internal compiler error: Error constructed but not emitted

thread 'rustc' panicked at 'explicit panic', librustc_errors/diagnostic_builder.rs:242:13
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: core::ops::function::Fn::call
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::begin_panic
   7: <rustc_errors::diagnostic_builder::DiagnosticBuilder<'a> as core::ops::drop::Drop>::drop
   8: syntax::ext::expand::MacroExpander::expand_invoc
   9: syntax::ext::expand::MacroExpander::expand
  10: syntax::ext::expand::MacroExpander::expand_crate
  11: rustc_driver::driver::phase_2_configure_and_expand_inner::{{closure}}
  12: rustc_driver::driver::phase_2_configure_and_expand_inner
  13: rustc_driver::driver::compile_input
14: rustc_driver::run_compiler

[ExpHP]

looks familiar...

[ExpHP]

I minimized rocket_codegen down 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

$ git clone https://github.com/ExpHP/Rocket-issue-48387
$ cargo build --example=issue-48387
   Compiling rocket_codegen v0.4.0-dev (file:///home/lampam/asd/clone/Rocket)
error: internal compiler error: Error constructed but not emitted

thread 'rustc' panicked at 'explicit panic', librustc_errors/diagnostic_builder.rs:242:13

A function that just loops surely cannot be responsible for dropping a DiagnosticBuilder, so the Error constructed but not emitted must be a bug in rustc.

(I still rather doubt it is in expand_invoc though, but rather, in a function that gets inlined into it)

[ExpHP]

So...

I mentioned in the other issue how terrifying of a concept I thought PResult was.

For the uninitiated, PResult is a type alias for a Result with a DiagnosticBuilder in its Err variant, which acts like a ticking timebomb; it explodes if the error is ever dropped. Simply put, Result has some methods that you must never call on a PResult.

rust/src/libsyntax/ext/expand.rs

Lines 486 to 490 in 883e746

	MultiModifier(ref mac) => {
	let meta = attr.parse_meta(self.cx.parse_sess).ok()?;
	let item = mac.expand(self.cx, attr.span, &meta, item);
	Some(kind.expect_from_annotatables(item))
	}

Do you see it? 😉

[estebank]

Ha! Thank you for the digging @ExpHP. That stray .ok() is really cheeky, ain't it?

[ExpHP]

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 the MultiDecorator(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 expand derive_FromForm.)

#![feature(plugin, custom_derive, decl_macro)]
#![plugin(rocket_codegen)]

// (this gives a regular syntax error, not an ICE)
#[derive(FromForm, (|x| x am pure)(I))]
struct DairyCheese;