Idea: rethink/rework #[instrument] codegen

[Swatinem]

Feature Request

Crates

tracing-attributes

Motivation

Primarily, the codegen right now does not correctly support hybrid-async functions (fn() -> impl Future that has both sync code, and returns an async block) #1863
The codegen also generates weird code in certain situations and can trigger some lints, for example #1831
It also does not support more than one return position for fn() -> Box<dyn Future>, as in #1840

We have a couple of patterns the codegen should cover, and apart from that there is optional support to log the return value which we have to cater for.

As for the input code patterns:

fn normal_sync_fn() -> Result<A, B> {
    if whatever()? {
        return Ok(A);
    }
    Err(B)
}

async fn normal_async_fn() -> Result<A, B> {
    if whatever().await? {
        return Ok(A);
    }
    Err(B)
}

fn manual_async_fn() -> impl Future<Output = Result<A, B>> {
    async move {
        if whatever().await? {
            return Ok(A);
        }
        Err(B)
    }
}

fn manual_boxed_async_block() -> Box<dyn Future<Output = Result<A, B>>> {
    Box::pin(async move {
        if whatever().await? {
            return Ok(A);
        }
        Err(B)
    })
}

fn manual_boxed_async_inner() -> Box<dyn Future<Output = Result<A, B>>> {
    async fn inner() -> Result<A, B> {
        if whatever().await? {
            return Ok(A);
        }
        Err(B)
    }
    Box::pin(inner())
}


fn manual_hybrid_fn() -> impl Future<Output = Result<A, B>> {
    let val = whatever();
    async move {
        if val.await? {
            return Ok(A);
        }
        Err(B)
    }
}

fn manual_hybrid_boxed_fn() -> Box<dyn Future<Output = Result<A, B>>> {
    let val = whatever();
    Box::pin(async move {
        if val.await? {
            return Ok(A);
        }
        Err(B)
    })
}

fn unbalanced_boxed_fn() -> Box<dyn Future<Output = Result<A, B>>> {
    if whatever() {
        return Box::pin(futureA());
    }
    Box::pin(futureB())
}

And then there is also the case that returns a named future, but I don’t think we can do anything in those, because its

1. impossible to wrap them in Instrumented
2. possibly impossible to detect without type checking that the return value is actually an impl Future.

Nice to haves

• Generate code that is possible to completely optimize out when compile-time level are defined
• Ideally avoid creating enter-guards when the span is disabled
• Avoid excessive async block wrapping when possible

Proposal

No concrete fleshed out proposal yet, just some brainstorming ;-)

Especially the unbalanced_boxed_fn case, and the cases involving return-value inspection are causing me headaches right now.

[Alfred-Mountfield]

Reworking #[instrument] could also possibly address #1841