diesel_codegen_syntex panics with underflow

[overdrivenpotato]

Example repository: https://github.com/overdrivenpotato/dcs_underflow
cargo build fails with an underflow error:

error: failed to run custom build command for `codegen_underflow v0.1.0 (file:///private/tmp/syntex_underflow)`
process didn't exit successfully: `/private/tmp/syntex_underflow/target/debug/build/codegen_underflow-9def5d0e1fb9752b/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'attempted to subtract with overflow', /Users/marko/.cargo/registry/src/github.com-1ecc6299db9ec823/syntex_pos-0.42.0/src/lib.rs:525
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Seems to be caused by #[derive(Queryable)] being the first line in a file, adding a space or anything else before the # prevents the issue.

#[derive(Queryable)]
struct T { _dummy: () }

fn main() {}

I'm not sure if this is a bug with diesel or syntex, let me know if I should move this over to the syntex issue tracker.

[sgrif]

TL;DR: Not sure if this is a bug in Diesel or rustc but we should see if we can fix it on our end, and there's a pretty straightforward way to do that. The rest of this comment are technical details on the issue which you may or may not find interesting.

Possibly boring technical details about the issue

So this actually has little to do with syntex, this bug can be reproduced with nightly and rustc plugins as well. I'm really not sure if this is a bug in rustc, Diesel, or neither. The issue comes from the code that we're generating. When building an AST everything takes a span which is basically a byte offset into a file. For code generation from derive, the span is pretty much always the span of the derive attribute itself, which in this case is byte 0. The code we'll be generating for that struct is:

impl<__ST, __DB> Queryable<__ST, __DB> for T where
    __DB: Backend + HasSqlType<__ST>,
    ((),): FromSqlRow<__ST, __DB>,
{
    type Row = ((),);

    fn build(row: Self::Row) -> Self {
        T {
            _dummy: row.0,
        }
    }
}

(Yes ((),) looks kind of silly but for this struct that is the tuple of the types of all fields on the struct). The issue comes from the row.0 part. When we try to construct that we're giving it that same span with the 0 byte offset. However, the compiler is trying to build a new span which starts at the dot and ends at the 0. It appears to be assuming that we are giving it a span which starts and ends at the 0. So it's subtracting 1 from the start, but in this case the start is 0 so it underflows.

I suspect that the assumptions the compiler is making about the span are incorrect. But that doesn't matter, as we can't demonstrate this as an issue through any public APIs and this is a private, internal API for rustc.

Interestingly, this code differs from what we would generate using our stable macro, which would be:

impl<__ST, __DB> Queryable for T where
    __DB: Backend + HasSqlType<__ST>,
    ((),): FromSqlRow<__ST, __DB>,
{
    type Row = ((),);

    fn build(row: Self::Row) -> Self {
        let (_dummy,) = row;
        T {
            _dummy: _dummy,
        }
    }
}

I've been changing all of our syntex/nightly macros to be implemented purely in terms of the stable macro form in order to get access to $crate. I thought I had already done that for Queryable but it looks like I missed it. Making that change should work around this issue.

[sgrif]

I've submitted a fix upstream either way. rust-lang/rust#35990

[sgrif]

This is a Rust issue not a diesel issue. rust-lang/rust#36081