Re: [PATCH v5 04/26] rust: alloc: implement `Allocator` for `Kmalloc`

[Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>]

On Wed, Aug 14, 2024 at 5:20 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> Indeed, and I think once they're honored we should add them again.
>
> It's just that I think as long as compiler attributes aren't honored, we should
> not have them in the first place to avoid confusion about whether they do or do
> not have any effect.

In the C side, many attributes are not honored anyway, depending on
the compiler (or tool like sparse), compiler version, etc. So it would
be "OK" in that sense (even if here we may know there is no C caller).

> It's not so much that I want to remove them for krealloc(), it's that I don't
> want to intentionally add them for the vrealloc() and kvrealloc() helpers,
> knowing that they don't do anything (yet).

One can think of them as "documentation", e.g. seeing `__must_check`
tells you something about the function, so I don't think it would be
bad to add them, if they are not too much work to maintain.

I checked about `__must_check`, because it would be nice if it is used
by `bindgen`, and it turns out it already does, but behind
`--enable-function-attribute-detection` (apparently for performance
reasons):

    int f(void);
    __attribute__((warn_unused_result)) int g(void);

gives:

    extern "C" {
        pub fn f() -> ::std::os::raw::c_int;
    }
    extern "C" {
        #[must_use]
        pub fn g() -> ::std::os::raw::c_int;
    }

So that one should be kept at the very least, and it is a good example
of potential improvements later on based on these attributes.

In general, I think it is not a bad idea to write this file like we
would write other C files, even if it is not a regular C file. And
adding more information to signatures is, after all, part of what we
do with Rust overall!

Cheers,
Miguel