panic during proc-macro invocation

[saghm]

trafficstars

Hello! We use this crate for the tests of the mongodb crate, and we recently ran into a case where instead of us getting a compiler error, the compiler panicked, which I've traced back to the proc macro provided by this crate. The smallest reproduction case I've been able to come up with uses tokio to define an async test and then invokes await on a future that involves a call to function_name:

Cargo.toml

[dependencies]
function_name = "0.2.0"
tokio = { version = "0.2.22", features = ["macros", "rt-threaded"] }

lib.rs

struct Foo(String);

impl Foo {
    async fn get(&self) -> Option<String> {
        Some(self.0.clone())
    }
}

#[tokio::test]
#[function_name::named]
async fn change_stream_insert() {
    let foo = Foo(function_name!().to_string());
    let Some(_s) = foo.get().await;
}

Compiling this gives the following error:

thread 'rustc' panicked at 'byte index 18446744073709551615 is out of bounds of ``', /rustc/c367798cfd3817ca6ae908ce675d1d99242af148/src/libcore/str/mod.rs:1987:47
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.45.1 (c367798cf 2020-07-26) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental

note: some of the compiler flags provided by cargo are hidden

If I replace the invocation of function_name!() with "foo_test", I get the following compiler error, which is what I'd expect:

error[E0005]: refutable pattern in local binding: `None` not covered
   --> src/main.rs:9:1
    |
9   | #[tokio::test]
    | ^^^^^^^^^^^^^^ pattern `None` not covered
    |
   ::: /home/saghm/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/option.rs:157:5
    |
157 |     None,
    |     ---- not covered
    |
    = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant
    = note: for more information, visit https://doc.rust-lang.org/book/ch18-02-refutability.html
    = note: the matched value is of type `std::option::Option<std::string::String>`
help: you might want to use `if let` to ignore the variant that isn't matched
    |
9   | if #[tokio::test { /* */ }
    |

error: aborting due to previous error

Notably, removing the tokio::test (and leaving the function_name!() invocation in place) also yields the correct compiler error, so I suspect that the issue is some sort of conflicting rewrites being done by the two proc macros.

I haven't been able to find any panics on code that should compile properly, so this isn't a super urgent issue, but I figured that I should still file an issue in case you happen to know how to fix it.

Thanks for all the work on this excellent crate!

[danielhenrymantilla]

Hey, sorry for the incredibly late answer, I somehow never got GH notifications about this repo 🙇

• Is the issue still happening with newer toolchains? It looks like a rustc compiler bug which may have been fixed since 🙂