Instrument attribute with async-trait breaks include_str

[Txuritan]

Bug Report

Version

tracing v0.1.15
tracing-futures v0.2.4

Platform

Windows (64-bit)

Crates

async-trait v0.1.35

Description

When adding #[tracing::instrument] to a function in a #[async_trait::async_trait] trait implementation, include_str will think its in the root of the src folder when its not.

File tree:

src/
+-- lib.rs
+-- example/
    +-- mod.rs
    +-- text.txt

lib.rs:

mod example;

#[async_trait::async_trait]
pub trait Test {
    async fn example(&self);
}

mod.rs:

use crate::Test;

#[derive(Debug)]
pub struct Example {}


#[async_trait::async_trait]
impl Test for Example {
    #[tracing::instrument]
    async fn example(&self) {
        let _text = include_str!("text.txt");
    }
}

[hawkw]

Hmm, that seems very weird. I'm guessing you've already tested that this cannot be reproduced with just instrument or async-trait?

[Txuritan]

I have, async-trait alone works fine (what I'm currently doing), instrument also works without a problem (not async though), it only happens when I add instrument with async-trait.

[hawkw]

Interesting, thanks!

@nightmared since you actually wrote the async-trait integration for instrument, perhaps you'd have more insight into this than I do?

[nightmared]

Hum, that's weird, I tried it and I couldn't reproduce ?

src/
src/ex
src/ex/mod.rs
src/ex/text.txt
src/lib.rs

And it compiles just fine (this is exactly your example above, with example renamed as ex because I was lazy when creating the folder :-D).
Without the file I get this error, that shows it fetches the file in the right folder:

error: couldn't read src/ex/text.txt: No such file or directory (os error 2)
  --> src/ex/mod.rs:11:21
   |
11 |         let _text = include_str!("text.txt");
   |                     ^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

Maybe I'm missing something ?

--

I guess we can compare configurations then: I used tracing/master and async-trait 0.1.30 for this test, with

$ cargo -V
cargo 1.45.0-nightly (40ebd5220 2020-06-01)
$ rustc -V
rustc 1.46.0-nightly (feb3536eb 2020-06-09)

[Txuritan]

Here's a repo of the project that I used to find the cause.

I'm using the latest stable:

E:\git\rust\tie>rustc -V
rustc 1.44.0 (49cae5576 2020-06-01)

If I'm meant to be using nightly then I didn't see it anywhere.

[nightmared]

It does build with nightly on my computer (and no you're not supposed to have to use nightly AFAIK). But you're right, it fails with stable !?

[nightmared]

That's worrying, i will install cargo-expand (-Zunstable-options --pretty=expanded isn't available on stable) and see if I can undertand what's going on, but I don't guarantee much, this is fairly cryptic :)

--

Edit: "cargo expand" calls nightly internally, as it relies on -Zunstable-options --pretty=expanded (if I got it right) :/
So no luck with that. I will try to find another way.

[Txuritan]

Funnily enough I tried that as well, and as it couldn't find the file it just replaced it with ().

[Txuritan]

Considering that nightly now works and didn't before, maybe something changed in the handling of proc-macros from 1.44 to 1.46.

Edit: I was using 1.43.1 before, I updated to see if that was the issue (it wasn't), so it would what ever version of nightly I had then.

[nightmared]

It was fixed somewhere between nightly-2020-05-15 and nightly-2020-05-30 (Understanding nothing in rustc, I falled back to doing some terrible manual bisecting to narrow the "fix time region" :-p).

[nightmared]

I will try to bisect it further, if I have the time (and courage). Had I to do a completely uneducated guess, I would have said this may be related to rust-lang/rust@d277904#diff-0e785ff001c38d0918429e6a9880f0cd ?

[nightmared]

It does build with the commit I linked previously, so it was fixed before d277904.

[nightmared]

I'm still in the process of narrowing it down, but with git-bisect run now (it's better at running scripts than I am :p).
I still have to bisect around 30 commits (so <5 steps), but it takes its time on my laptop. Anyway, we will get to the bottom of this !

[nightmared]

Great ! Apparently it's rust-lang/rust@9b2b8a5, which is weird, but who am I to understand rustc anyway ? :-p

[nightmared]

Do I have to open an issue on rust ?

--
Edit: this really looks like a bug on rustc's side, so I opened a bug anyway. I hope building 8 times rustc and twice llvm will have been of some help. I guess it's no longer in our hands now ^^

[hawkw]

Closing this as wontfix, since it's an upstream compiler bug and there's nothing we can really do about it (see also #768 (comment)).

[hawkw]

Thanks @nightmared for all your hard work trying to figure this one out!

[nightmared]

Well, at least it confirms that this is fixed by the same commits @taiki-e talked about in #768, so it's not time completely wasted ^^