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

[Andreas Hindborg <a.hindborg@kernel.org>]

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

> On Fri, May 2, 2025 at 8:57 AM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>>
>> Right, they are not from const context, but they are inside a `let`
>> statement, so if all the captured variables are constant (which they
>> are), the let statement will be evaluated in const context [1], right?
>
> No, I don't think so. Though I don't know what you mean by "captured
> variables" here or why you point to [const-eval.const-context.init].

I see. it is not guaranteed, but it _may_ be.

Regarding captured variables, I was referring to "any operands". From
[const-eval.const-context.init]:

  Const context is one of the following:
  ...
  The initializer of statics.

From [const-eval.const-expr.list]:

  The following expressions are constant expressions, so long as any
  operands are also constant expressions and do not cause any Drop::drop
  calls to be run.

  ...

[const-eval.const-expr.block]:

  ...

  let statements

So I was thinking that because I am initializing a static with a let
statement, it would run in const context. But I see that it is not
actually guaranteed.

> The way I read the reference is that Rust only guarantees evaluation
> at compile-time within const contexts, and a `let` statement is not a
> const context and its initializer is not one of the ones listed in
> [const-eval.const-context.init]. `const fn` isn't a const context
> either.

I agree. No guarantees, [const-eval.const-expr.runtime-context]:

  In other places, such as let statements, constant expressions may be,
  but are not guaranteed to be, evaluated at compile time.

> Which makes sense -- the `let` initializers are just "normal"
> expressions, i.e. you don't want to limit the kinds of code you can
> run there.
>
> For instance, here there is a panic at runtime trying to mimic a bit the patch:
>
>     https://godbolt.org/z/v5qdK9vve
>
> Similarly, if I take your patch and put there an `assert!(false)` in
> `add` -- I see no build error and `objdump` shows the panic call from
> the sample.

Right. Which is why I opted for `build_error`. But with the `const`
block solution you suggested is better.


Best regards,
Andreas Hindborg