Received-SPF: pass (google.com: domain of linux-kernel+bounces-205952-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Precedence: bulk
MIME-Version: 1.0
References: <20240606193318.GK8774@noisy.programming.kicks-ass.net>
 <20240607094329.3878781-1-aliceryhl@google.com> <20240607105232.GP8774@noisy.programming.kicks-ass.net>
In-Reply-To: <20240607105232.GP8774@noisy.programming.kicks-ass.net>
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date: Fri, 7 Jun 2024 13:46:16 +0200
Message-ID: <CANiq72=4y84CrmkP-QsrW7YYNbpNJRim3oFK=kfEE8oin38pMQ@mail.gmail.com>
Subject: Re: [PATCH 1/3] rust: add static_call support
To: Peter Zijlstra <peterz@infradead.org>
Cc: Alice Ryhl <aliceryhl@google.com>, a.hindborg@samsung.com, alex.gaynor@gmail.com, 
	ardb@kernel.org, benno.lossin@proton.me, bjorn3_gh@protonmail.com, 
	boqun.feng@gmail.com, gary@garyguo.net, jbaron@akamai.com, 
	jpoimboe@kernel.org, linux-kernel@vger.kernel.org, 
	linux-trace-kernel@vger.kernel.org, mathieu.desnoyers@efficios.com, 
	mhiramat@kernel.org, ojeda@kernel.org, rostedt@goodmis.org, 
	rust-for-linux@vger.kernel.org, wedsonaf@gmail.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 7, 2024 at 12:52=E2=80=AFPM Peter Zijlstra <peterz@infradead.or=
g> wrote:
>
> I'm sorry, but 30+ years of reading ! as NOT (or factorial) isn't going
> to go away. So I'm reading your macros do NOT rule.

It makes it clear what is macro call or not. They could have gone for
UPPERCASE names (for instance), yes. On the other hand, they do not
work like C macros and are ~hygienic, so it also makes sense to avoid
confusion here.

I mean, I am not suggesting to do a CPP-pass to Rust files, but if
someone really, really wanted to mix them in a single file, it would
be nice to not confuse the two kinds. :)

Generally they feel "closer" to the language (given what they
do/support) compared to the CPP ones, so it also makes sense they
don't "shout" so much compared to UPPERCASE, if that makes sense.

> The above exaple fails, because the next token is :ident, whatever the
> heck that might be. Also, extra points for line-noise due to lack of
> whitespace.

$name:ident means "match what Rust would consider an identifier here
and call it $name for the purposes of this macro".

So, for instance, $x:ident matches:

    a
    a2
    a_b

But it would not match:

    2a
    a-b
    a _b

For the usual reasons why those are not identifiers.

https://godbolt.org/z/G7v4j67dc

    fn f(x: i32) -> i32 {
        x * 2
    }

    macro_rules! f {
        ($x:ident) =3D> { $x * 2 }
    }

    fn main() {
        let a =3D 42;

        let b =3D f(a);       // Function.
        let c =3D f!(a);      // Macro.

        //let c =3D f!(a2);   // Works, but the variable does not exist.
        //let c =3D f!(2a);   // Error: no rules expected the token `2a`.

        //let c =3D f!(a_b);  // Works, but the variable does not exist.
        //let c =3D f!(a-b);  // Error: no rules expected the token `-`.
        //let c =3D f!(a_ b); // Error: no rules expected the token `b`.

        println!("{a} {b} {c}");
    }

I hope this makes it clearer.

> You just need to extend the rust thing to be able to consume C header
> files.

I agree, because in practice it is quite useful for a language like
Rust that consuming C header files is "natively" supported.

Though it also has downsides and is a big decision, which is why, like
Alice mentioned, some people agree, and some people don't.
Nevertheless, we have been doing our best for a long time to get the
best we can for the kernel -- just 2 days ago we told the Rust project
in one of our meetings that it would be nice to see that particular
"project goal" from that document realized (among others).

Cheers,
Miguel