Hacker News Reader

Comment by masklinn | Hacker News Reader

> This is, in fact, the default. You can use the attributes to inform the optimizer of your wishes, if you want more control.

Isn't the default that the optimiser will do whatever the hell it wants, and the attributes simply skew the optimiser's factors in one direction or another? I think what the author means here is that the caller function should be able to define whether the callee should be inlined or not.

> The bindgen tool can help here.

Would be really useful to have an implicit bindgen thing. Maybe a compiler plugin using e.g. Clang's C parser? That way there's no need to maintain the binding. I'd say I'd like a header generator more than a reader though.

View on HN

Bindgen has a compiler plugin too: https://github.com/crabtw/rust-bindgen#macro-usage

Also, FYI, https://github.com/rust-lang/rust/issues/10530 covers taking a Rust lib and generating a C header file.

Maybe I misunderstood what the parent wants, but you're right that the optimizer can do as it pleases, and you can use annotations to help it make the right decision.

An 'implicit' tool may in fact be cool. It's not perfect, and so needs tweaking in many cases, so the current state is pretty good, but for easier cases and/or when you don't care, I can see such a thing being useful.

But those annotations are for the function definition instead of the call site, or are there call site annotations as well? I think the author's idea is analogous to the user-defined (instead of type-defined) move/copy semantics.

They're on the function definition, yes. There aren't ones at the call site.

Then I'm left wondering how you interpreted the sentence you quoted and replied to...?

> I’ve always thought it should be up to the caller to say which functions they’d like inlined,

I am ridiculously tired, after burning the candle from both ends for the last few weeks to get this release shipped. In the last four days, I've written almost 1700 lines of docs. I make mistakes sometimes :)

As someone who just looked this up to confirm this and reply to someone else here, the docs[1] are fairly ambiguous in this respect. As someone soliciting feedback on the docs, that's a good spot to clarify. :)

P.S. I considered submitting a PR, but I don't know enough about rust yet to accurately phrase it.

1: https://doc.rust-lang.org/reference.html#inline-attributes

> Maybe I misunderstood what the parent wants, but you're right that the optimizer can do as it pleases, and you can use annotations to help it make the right decision.

I understand TFAA's request to be a callsite annotation, which currently does not exist, e.g.

    inline foo()

to force inlining or

    noinline bar()

to prevent it, probably with the first one erroring out if the call is not inlinable.

I believe #[inline(always)] and #[inline(never)] both work like this.

According to steveklabnik here[1], those are on the definition, not the callsite, which is the distinction here. Although from other info here, it sounds like having it on the definition is a prerequisite in some cases if you wanted to somehow specify it for the callsite, as it needs to be serialized in the crate metadata to be inline-able, and that's controlled somewhat by whether it was defined as inline capable.

1: https://news.ycombinator.com/item?id=9548248

Bindgen uses libclang. It's also quite slow.

Reply on news.ycombinator.com