GGreg Kroah-Hartmanrust: use #[used(compiler)] to fix build and modpost with Rust >= 1.89.0
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
rust: macros: add concat_idents! proc macro This macro provides similar functionality to the unstable feature concat_idents without having to rely on it. For instance: let x_1 = 42; let x_2 = concat_idents!(x, _1); assert!(x_1 == x_2); It has different behavior with respect to macro hygiene. Unlike the unstable concat_idents! macro, it allows, for example, referring to local variables by taking the span of the second macro as span for the output identifier. Signed-off-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Reviewed-by: Finn Behrens <me@kloenk.dev> Reviewed-by: Gary Guo <gary@garyguo.net> [Reworded, adapted for upstream and applied latest changes] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> | 3 年前 | |
rust: macros: allow generic parameter default values in #[pin_data] Add support for generic parameters defaults in #[pin_data] by using the newly introduced decl_generics instead of the impl_generics. Before this would not compile: #[pin_data] struct Foo<const N: usize = 0> { // ... } because it would be expanded to this: struct Foo<const N: usize = 0> { // ... } const _: () = { struct __ThePinData<const N: usize = 0> { __phantom: ::core::marker::PhantomData<fn(Foo<N>) -> Foo<N>>, } impl<const N: usize = 0> ::core::clone::Clone for __ThePinData<N> { fn clone(&self) -> Self { *self } } // [...] rest of expansion omitted }; The problem is with the impl<const N: usize = 0>, since that is invalid Rust syntax. It should not mention the default value at all, since default values only make sense on type definitions. The new impl_generics do not contain the default values, thus generating correct Rust code. This is used by the next commit that puts #[pin_data] on kernel::workqueue::Work. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240309155243.482334-2-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org> | 2 年前 | |
rust: kbuild: expand rusttest target for macros commit b2c261fa8629dff2bd1143fa790797a773ace102 upstream. Previously, the rusttest target for the macros crate did not specify the dependencies necessary to run the rustdoc tests. These tests rely on the kernel crate, so add the dependencies. Signed-off-by: Ethan D. Twardy <ethan.twardy@gmail.com> Link: https://github.com/Rust-for-Linux/linux/issues/1076 Link: https://lore.kernel.org/r/20240704145607.17732-2-ethan.twardy@gmail.com [ Rebased ( alloc is gone nowadays, sysroot handling is simpler) and simplified (reused rustdoc_test rule instead of adding a new one, no need for rustdoc-compiler_builtins, removed unneeded macros explicit path). Made vtable example fail (avoiding to increase the complexity in the rusttest target). Removed unstable -Zproc-macro-backtrace option. Reworded accordingly. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: use #[used(compiler)] to fix build and modpost with Rust >= 1.89.0 commit 7498159226772d66f150dd406be462d75964a366 upstream. Starting with Rust 1.89.0 (expected 2025-08-07), the Rust compiler fails to build the rusttest target due to undefined references such as: kernel...-cgu.0:(.text....+0x116): undefined reference to rust_helper_kunit_get_current_test' Moreover, tooling like modpost gets confused: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/nova/nova.o ERROR: modpost: missing MODULE_LICENSE() in drivers/gpu/nova-core/nova_core.o The reason behind both issues is that the Rust compiler will now [1] treat #[used] as #[used(linker)] instead of #[used(compiler)] for our targets. This means that the retain section flag (R, SHF_GNU_RETAIN) will be used and that they will be marked as unique too, with different IDs. In turn, that means we end up with undefined references that did not get discarded in rusttest and that multiple .modinfo sections are generated, which confuse tooling like modpost because they only expect one. Thus start using #[used(compiler)] to keep the previous behavior and to be explicit about what we want. Sadly, it is an unstable feature (used_with_arg) [2] -- we will talk to upstream Rust about it. The good news is that it has been available for a long time (Rust >= 1.60) [3]. The changes should also be fine for previous Rust versions, since they behave the same way as before [4]. Alternatively, we could use #[no_mangle] or #[export_name = ...] since those still behave like #[used(compiler)]`, but of course it is not really what we want to express, and it requires other changes to avoid symbol conflicts. Cc: David Wood <david@davidtw.co> Cc: Wesley Wiser <wwiser@gmail.com> Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust/pull/140872 [1] Link: https://github.com/rust-lang/rust/issues/93798 [2] Link: https://github.com/rust-lang/rust/pull/91504 [3] Link: https://godbolt.org/z/sxzWTMfzW [4] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Björn Roy Baron <bjorn3_gh@protonmail.com> Link: https://lore.kernel.org/r/20250712160103.1244945-3-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 10 个月前 | |
rust: macros: update 'paste!' macro to accept string literals Enable combining identifiers with literals in the 'paste!' macro. This allows combining user-specified strings with affixes to create namespaced identifiers. This sample code: macro_rules! m { ($name:lit) => { paste!(struct [<_some_ $name _struct_>] {}) } } m!("foo_bar"); Would previously cause a compilation error. It will now generate: struct _some_foo_bar_struct_ {} Signed-off-by: Trevor Gross <tmgross@umich.edu> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20231118013959.37384-1-tmgross@umich.edu [ Added : before example block. ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> | 2 年前 | |
rust: macros: allow generic parameter default values in #[pin_data] Add support for generic parameters defaults in #[pin_data] by using the newly introduced decl_generics instead of the impl_generics. Before this would not compile: #[pin_data] struct Foo<const N: usize = 0> { // ... } because it would be expanded to this: struct Foo<const N: usize = 0> { // ... } const _: () = { struct __ThePinData<const N: usize = 0> { __phantom: ::core::marker::PhantomData<fn(Foo<N>) -> Foo<N>>, } impl<const N: usize = 0> ::core::clone::Clone for __ThePinData<N> { fn clone(&self) -> Self { *self } } // [...] rest of expansion omitted }; The problem is with the impl<const N: usize = 0>, since that is invalid Rust syntax. It should not mention the default value at all, since default values only make sense on type definitions. The new impl_generics do not contain the default values, thus generating correct Rust code. This is used by the next commit that puts #[pin_data] on kernel::workqueue::Work. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Tested-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240309155243.482334-2-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org> | 2 年前 | |
rust: clean Rust 1.88.0's clippy::uninlined_format_args lint commit 211dcf77856db64c73e0c3b9ce0c624ec855daca upstream. Starting with Rust 1.88.0 (expected 2025-06-26) [1], rustc may move back the uninlined_format_args to style from pedantic (it was there waiting for rust-analyzer suppotr), and thus we will start to see lints like: warning: variables can be used directly in the format! string --> rust/macros/kunit.rs:105:37 | 105 | let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args help: change this to | 105 - let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test); 105 + let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{test}"); There is even a case that is a pure removal: warning: variables can be used directly in the format! string --> rust/macros/module.rs:51:13 | 51 | format!("{field}={content}\0", field = field, content = content) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args help: change this to | 51 - format!("{field}={content}\0", field = field, content = content) 51 + format!("{field}={content}\0") The lints all seem like nice cleanups, thus just apply them. We may want to disable allow-mixed-uninlined-format-args in the future. Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs). Link: https://github.com/rust-lang/rust-clippy/pull/14160 [1] Acked-by: Benno Lossin <lossin@kernel.org> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250502140237.1659624-6-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 1 年前 | |
rust: add derive macro for Zeroable Add a derive proc-macro for the Zeroable trait. The macro supports structs where every field implements the Zeroable trait. This way unsafe implementations can be avoided. The macro is split into two parts: - a proc-macro to parse generics into impl and ty generics, - a declarative macro that expands to the impl block. Suggested-by: Asahi Lina <lina@asahilina.net> Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Link: https://lore.kernel.org/r/20230814084602.25699-4-benno.lossin@proton.me [ Added ignore to the lib.rs example and cleaned trivial nit. ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> | 2 年前 | |
rust: macros: vtable: fix HAS_* redefinition (gen_const_name) If we define the same function name twice in a trait (using #[cfg]), the vtable macro will redefine its gen_const_name, e.g. this will define HAS_BAR twice: #[vtable] pub trait Foo { #[cfg(CONFIG_X)] fn bar(); #[cfg(not(CONFIG_X))] fn bar(x: usize); } Fixes: b44becc5ee80 ("rust: macros: add #[vtable] proc macro") Signed-off-by: Qingsong Chen <changxian.cqs@antgroup.com> Reviewed-by: Andreas Hindborg <a.hindborg@samsung.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Sergio González Collado <sergio.collado@gmail.com> Link: https://lore.kernel.org/r/20230808025404.2053471-1-changxian.cqs@antgroup.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org> | 2 年前 | |
rust: macros: add decl_generics to parse_generics() The generic parameters on a type definition can specify default values. Currently parse_generics() cannot handle this though. For example when parsing the following generics: <T: Clone, const N: usize = 0> The impl_generics will be set to T: Clone, const N: usize = 0 and ty_generics will be set to T, N. Now using the impl_generics on an impl block: impl<$($impl_generics)*> Foo {} will result in invalid Rust code, because default values are only available on type definitions. Therefore add parsing support for generic parameter default values using a new kind of generics called decl_generics and change the old behavior of impl_generics to not contain the generic parameter default values. Now Generics has three fields: - impl_generics: the generics with bounds (e.g. T: Clone, const N: usize) - decl_generics: the generics with bounds and default values (e.g. T: Clone, const N: usize = 0) - ty_generics: contains the generics without bounds and without default values (e.g. T, N) impl_generics is designed to be used on impl<$impl_generics>, decl_generics for the type definition, so struct Foo<$decl_generics> and ty_generics whenever you use the type, so Foo<$ty_generics>. Here is an example that uses all three different types of generics: let (Generics { decl_generics, impl_generics, ty_generics }, rest) = parse_generics(input); quote! { struct Foo<$($decl_generics)*> { // ... } impl<$impl_generics> Foo<$ty_generics> { fn foo() { // ... } } } The next commit contains a fix to the #[pin_data] macro making it compatible with generic parameter default values by relying on this new behavior. Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20240309155243.482334-1-benno.lossin@proton.me Signed-off-by: Miguel Ojeda <ojeda@kernel.org> | 2 年前 |