Change:
I noticed that in one of my project, inlining [] manually reduces some binary size, then I noticed is not marked . Since both [] and [] are marked , I wonder whether this is an oversight. I failed to reproduce the binary size reduction effect with an example code, but maybe the reason behind inlining and also applies to ? How about [] and []? []: []: []: []: []:
That's surprising. Can you share your project?
Unfortunately, it is a private project, I cannot share it.
Ah okay. I find it suspicious that these functions aren't inlining already. Did you try building your project against a modified standard library with to those functions? Do you still get a code size improvement from manual inlining if you compile with and/or in your release profile? The functions in question ought to already be eligible for inlining, but by default the release profile has multiple codegen units per crate, which can result in surprising failures to inline things. How big are these functions once they are compiled in your crate? The third-party tool can help out here, can you share the output of (of course trimming that down a bit if there are type names in there you don't want to fully disclose) If for whatever reason these functions end up looking big to LLVM after other things are inlined into them, that may explain what's going on here, and your manual inlining has effectively changed in what order LLVM considers inlining things.
I have done some tests on my project, using to check for symbols: Using , does not get inlined; Using , gets inlined; Using and , add to standard library source code, gets inlined; All configurations above are using and . reports that each is about 68 to 96 bytes.
What about and to the standard library code, but without using ? If that configuration gets these functions inlined I think this is worth doing because it unlocks additional useful optimizations for users, but if the optimization is gated behind it's a bit less certain if this is a win. Do you or any other LLVM folks have insight into why would be impactful here? Are we relying on the hint part of its behavior?
It seems that changing standard library source code only works with . Do I need to compile a customized version of Rust in order to test it?
That's what I do. It's a very slow workflow.

Discussion:
/// assert_eq!(poll_some_len, Poll::Ready(13)); /// ``` #[stable(feature = "futures_api", since = "1.36.0")] <ins> #[inline] </ins> pub fn map<U, F>(self, f: F) -> Poll<U> where F: FnOnce(T) -> U,

/// assert_eq!(squared, Poll::Ready(Ok(144))); /// ``` #[stable(feature = "futures_api", since = "1.36.0")] <ins> #[inline] </ins> pub fn map_ok<U, F>(self, f: F) -> Poll<Result<U, E>> where F: FnOnce(T) -> U,

/// assert_eq!(res, Poll::Ready(Err(0))); /// ``` #[stable(feature = "futures_api", since = "1.36.0")] <ins> #[inline] </ins> pub fn map_err<U, F>(self, f: F) -> Poll<Result<T, U>> where F: FnOnce(E) -> U,

/// assert_eq!(squared, Poll::Ready(Some(Ok(144)))); /// ``` #[stable(feature = "poll_map", since = "1.51.0")] <ins> #[inline] </ins> pub fn map_ok<U, F>(self, f: F) -> Poll<Option<Result<U, E>>> where F: FnOnce(T) -> U,

/// assert_eq!(res, Poll::Ready(Some(Err(0)))); /// ``` #[stable(feature = "poll_map", since = "1.51.0")] <ins> #[inline] </ins> pub fn map_err<U, F>(self, f: F) -> Poll<Option<Result<T, U>>> where F: FnOnce(E) -> U,