[tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
------------------------------+------------------------------------
 Reporter:  isis              |          Owner:  chelseakomlo
     Type:  enhancement       |         Status:  needs_revision
 Priority:  High              |      Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor      |        Version:
 Severity:  Normal            |     Resolution:
 Keywords:  rust, rust-pilot  |  Actual Points:
Parent ID:                    |         Points:  3
 Reviewer:                    |        Sponsor:
------------------------------+------------------------------------

Comment (by manish.earth):

 > Would you recommend using the #[inline] tag for that function then?

 yep.

 To give an exact description of #[inline]:

 For the *same* crate it acts as a small hint for inlining. This is also
 true for generics that get instantiated in a different crate.

 For non-generic functions from a different crate, it is impossible for
 rustc to inline without this, because by the time you get to the current
 crate it's already been codegenned. #[inline] forces rustc to include
 extra metadata that lets the next crate re-codegen it if it wishes to. (It
 also contains the small hint for inlining)

 #[inline(always)] is a *strong* hint, and will force inlining unless it's
 impossible (e.g. in the presence of a lot of recursion). #[inline(never)]
 does what it says on the tin.

 In this case it's a macro and going to be used from a different crate, so
 we _need_ `#[inline]` so that the other crate can inline it if the
 optimizer thinks it is a good idea. We don't need inline(always) -- the
 optimizer is smart.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23881#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online