fastrace override for #[trace]

[Tamschi]

Feature Request

Crates

fastrace-macro

Motivation

As the #[trace] macro is unable to use $crate, it currently (unhygienically) grabs fastrace from the locally available names.
This generally works fine if the crate where that attribute ends up actually depends on fastrace directly, but it fails when fastrace is only a transitive dependency and has not been imported.

In my case specifically, I'd like to auto-instrument components generated by my UI component framework, which aren't simple functions.

Proposal

I would like to implement an additional parameter for #[trace] like this:

#[trace(fastrace = some_path)]

where some_path is a path expression leading to the fastrace module.

When no fastrace argument is available, some_path should default to just fastrace with call site resolution, as before.

The hygiene information on those path tokens should be preserved to make it easier to use in other macros, but this is the default when pasting into a quote!(…) anyway, so I don't see a reason not to handle it like that.

Alternatives

I could document my framework to tell users to add a specific version of fastrace with relevant features to their dependencies to use a new "fastrace" feature I'd add, which is less than ideal because the crate that uses my macro could be a library not otherwise depending on fastrace itself, and would then have to expose that as feature in turn.
Since fastrace-instrumentation should be zero-cost when tracing is disabled, I'd like to enable it unconditionally instead, but without complicating my library's use.

I could also emit a use … as fastrace; import statement, but this adds an item to the consumer-visible namespace and can lead to unexpected collisions (or shadowing, if I rewrite some of my code to scope it).

[Tamschi]

This is essentially a copy of this feature request I filed with Tracing in early 2022 and submitted an implementation for, but unfortunately my pull-request never got processed despite maintainers' initial tentative approval.

I'm still working on-and-off on my framework, as time permits, and still need a good tracing system that can instrument async functions and blocks. I also think this feature would be helpful for other macro authors.

You can look at the changes submitted there to see roughly how I'd do this, of course adapted to this project's code style instead of Tracing's.
I'd just like confirmation that my submission would at least get reviewed once, since it's not super fun to do work and then get ghosted by the project team.

[Tamschi]

Whoops, forgot to adjust the title of all things. Sorry about that 😅

[andylokandy]

Thanks for investigating fastrace :)

I suggest using the underlying building blocks i.e., Span and LocalSpan. This approach provides fine-grained control, and improves compile performance, especially for the generated code (as mentioned in the UI framework).

[Tamschi]

In theory yes, though it would make my macro more complex.
(There are user-provided Rust expressions that I currently don't interact with at all, which may contain closures and async, so I'd still have to scan through them.)

You're right though, I'll see if I can integrate this easily in other ways first.

[andylokandy]

Is it possible to address the very first issue by reexporting fastrace into your library and expanding your macro like this:

#[your_macro]
fn user_function() {
    // user code ...
}

// expands to

fn user_function() {
    use your_crate::reexport::fastrace;

    #[fastrace::trace]
    fn inner() {
        // user code ...
    }

    inner()
}

[Tamschi]

Likely yes, but only because the macro currently isn't hygienic.

Fixing this part of hygiene by default would be a breaking change, so I'll submit it separately, but I'd like to be able to specify a fully qualified path for fastrace either way.

Edit: Though, I think I would have fewer issues here from the get-go, since fastrace isn't a common word.