Rust for Linux List
 help / color / mirror / Atom feed
From: Gary Guo <gary@garyguo.net>
To: "Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Tamir Duberstein" <tamird@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Onur Özkan" <work@onurozkan.dev>,
	"Breno Leitao" <leitao@debian.org>,
	"Luis Chamberlain" <mcgrof@kernel.org>,
	"Russ Weight" <russ.weight@linux.dev>,
	"Lyude Paul" <lyude@redhat.com>
Cc: linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
	 driver-core@lists.linux.dev, Gary Guo <gary@garyguo.net>
Subject: [PATCH 0/4] rust: add `#[macro_export_scoped]` for scoped declarative macro
Date: Tue, 11 Aug 2026 13:25:52 +0100	[thread overview]
Message-ID: <20260811-macro_export_scoped-v1-0-e7782b102819@garyguo.net> (raw)

Rust's declarative macro scoping rule is confusing because it was
historically purely textual scoped and the path-based scoping is added as
an afterthought.

`#[macro_export]` will make the macro available for use outside the crate,
but it also adds the macro to the root of crate. This has the issue where
it prevents us from cleanly put things in modules where they belong. Macro
2.0 is supposed to address this issue, but currently it seems that we are
unlikely to get macro 2.0 any time soon.

There is a way to approximate the scoping -- hide the macro from the crate
root using `#[doc(hidden)]`, and then re-export the macro from where they
are supposed to appear, and undo the `#[doc(hidden)]` with
`#[doc(inline)]`. We have used this approach for a few macros already.
This is not fully bullet-proof; users can still reference the items from
crate root, as it is hidden from documentation but is still present in name
resolution.

Introduce a macro `#[macro_export_scoped]`, that implements the above
trick, so people can create new properly-scoped macros easily. Also, adopt
a solution where we assign the macros non-guessable names, and then just
re-export them under intended name. This removes the possibility of
using the macro from incorrect path unintentionally.

Signed-off-by: Gary Guo <gary@garyguo.net>
---
Gary Guo (4):
      rust: macros: add `#[macro_export_scoped]`
      rust: build_assert: remove macro from crate root
      rust: list: convert to use `#[macro_export_scoped]`
      rust: io: convert to use `#[macro_export_scoped]`

 rust/kernel/build_assert.rs            | 24 +++++----------
 rust/kernel/configfs.rs                |  4 +--
 rust/kernel/firmware.rs                |  4 +--
 rust/kernel/io.rs                      | 27 +++++++----------
 rust/kernel/list/arc.rs                |  4 +--
 rust/kernel/list/arc_field.rs          |  4 +--
 rust/kernel/list/impl_list_item_mod.rs | 14 ++++-----
 rust/kernel/ptr.rs                     |  6 +---
 rust/kernel/sync/atomic.rs             |  2 +-
 rust/macros/lib.rs                     | 25 ++++++++++++++++
 rust/macros/macro_export_scoped.rs     | 53 ++++++++++++++++++++++++++++++++++
 11 files changed, 108 insertions(+), 59 deletions(-)
---
base-commit: 6b8c8af514d739d0335f5579b585e02babe8a727
change-id: 20260811-macro_export_scoped-5ce38b5db968

Best regards,
--  
Gary Guo <gary@garyguo.net>


             reply	other threads:[~2026-08-11 12:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-11 12:25 Gary Guo [this message]
2026-08-11 12:25 ` [PATCH 1/4] rust: macros: add `#[macro_export_scoped]` Gary Guo
2026-08-11 12:25 ` [PATCH 2/4] rust: build_assert: remove macro from crate root Gary Guo
2026-08-12 10:33   ` Andreas Hindborg
2026-08-11 12:25 ` [PATCH 3/4] rust: list: convert to use `#[macro_export_scoped]` Gary Guo
2026-08-11 12:25 ` [PATCH 4/4] rust: io: " Gary Guo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260811-macro_export_scoped-v1-0-e7782b102819@garyguo.net \
    --to=gary@garyguo.net \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=driver-core@lists.linux.dev \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=lyude@redhat.com \
    --cc=mcgrof@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=russ.weight@linux.dev \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tamird@kernel.org \
    --cc=tmgross@umich.edu \
    --cc=work@onurozkan.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox