[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs