Re: [PATCH v6 1/3] rust: configfs: introduce rust support for configfs

[Miguel Ojeda]

On Thu, May 1, 2025 at 8:11 PM Andreas Hindborg <a.hindborg@xxxxxxxxxx> wrote:
>
> But why does that matter? Anything in the commit message after the cut
> is dropped when applying the patch, right?

Yes, but it is not common to add a newline there. I mentioned it
because it looked odd, no worries.

> I might not have the full picture, but it is my understanding that
> while `const fn` are evaluated in const context when called from const
> context, they _may_ be called from non-const context, and then they are
> evaluated in non-const context if their arguments are not const [1].
> They are not guaranteed to be evaluated in const context.
>
> So my thinking is that down the road, refactoring of this code may cause
> the `AttributeList::add` to be called in a way so that it is not
> evaluated in const context, and then the `assert` would be evaluated at
> run time. With `build_error` we would get an error during build.

No, it will always be evaluated at compile-time (if it is evaluated at all).

Please see again the links I provided. There is no `const fn` in the
example I provided, and yet it is a build error.

>From your link, it is clear `const` blocks are a const context, which
are always evaluated at compile time:

    Certain forms of expressions, called constant expressions, can be
    evaluated at compile time.

    In const contexts, these are the only allowed expressions, and are
    always evaluated at compile time.

    A const context is one of the following: (...) A const block

And from mine, it mentions that it is guaranteed to be evaluated if
execution reaches that point and that such evaluation would happen at
compile time:

    A const block is a variant of a block expression whose body
    evaluates at compile-time instead of at runtime.

    If the const block expression is executed at runtime, then the
    constant is guaranteed to be evaluated, even if its return value is
    ignored:

        fn foo<T>() -> usize {
            // If this code ever gets executed, then the assertion has
            // definitely been evaluated at compile-time.
            const { assert!(std::mem::size_of::<T>() > 0); }
            // Here we can have unsafe code relying on the type being
            // non-zero-sized.
            /* ... */
            42
        }

That example they give is precisely about using a `const` block for
guaranteeing something that unsafe code relies on.

I hope that helps.

Cheers,
Miguel