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

[Andreas Hindborg]

"Miguel Ojeda" <miguel.ojeda.sandonis@xxxxxxxxx> writes:

> 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.

Ah - I understand. I missed that you wrapped the assert in a const
block, a quite important bit 🤦 Thanks for explaining!


Best regards,
Andreas Hindborg