mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-09-21 12:11:49 +08:00
Merge branch 'rust-fixes' of https://github.com/Rust-for-Linux/linux.git
This commit is contained in:
commit
4a2730bf07
@ -145,32 +145,32 @@ This is how a well-documented Rust function may look like:
|
||||
This example showcases a few ``rustdoc`` features and some conventions followed
|
||||
in the kernel:
|
||||
|
||||
- The first paragraph must be a single sentence briefly describing what
|
||||
the documented item does. Further explanations must go in extra paragraphs.
|
||||
- The first paragraph must be a single sentence briefly describing what
|
||||
the documented item does. Further explanations must go in extra paragraphs.
|
||||
|
||||
- Unsafe functions must document their safety preconditions under
|
||||
a ``# Safety`` section.
|
||||
- Unsafe functions must document their safety preconditions under
|
||||
a ``# Safety`` section.
|
||||
|
||||
- While not shown here, if a function may panic, the conditions under which
|
||||
that happens must be described under a ``# Panics`` section.
|
||||
- While not shown here, if a function may panic, the conditions under which
|
||||
that happens must be described under a ``# Panics`` section.
|
||||
|
||||
Please note that panicking should be very rare and used only with a good
|
||||
reason. In almost all cases, a fallible approach should be used, typically
|
||||
returning a ``Result``.
|
||||
Please note that panicking should be very rare and used only with a good
|
||||
reason. In almost all cases, a fallible approach should be used, typically
|
||||
returning a ``Result``.
|
||||
|
||||
- If providing examples of usage would help readers, they must be written in
|
||||
a section called ``# Examples``.
|
||||
- If providing examples of usage would help readers, they must be written in
|
||||
a section called ``# Examples``.
|
||||
|
||||
- Rust items (functions, types, constants...) must be linked appropriately
|
||||
(``rustdoc`` will create a link automatically).
|
||||
- Rust items (functions, types, constants...) must be linked appropriately
|
||||
(``rustdoc`` will create a link automatically).
|
||||
|
||||
- Any ``unsafe`` block must be preceded by a ``// SAFETY:`` comment
|
||||
describing why the code inside is sound.
|
||||
- Any ``unsafe`` block must be preceded by a ``// SAFETY:`` comment
|
||||
describing why the code inside is sound.
|
||||
|
||||
While sometimes the reason might look trivial and therefore unneeded,
|
||||
writing these comments is not just a good way of documenting what has been
|
||||
taken into account, but most importantly, it provides a way to know that
|
||||
there are no *extra* implicit constraints.
|
||||
While sometimes the reason might look trivial and therefore unneeded,
|
||||
writing these comments is not just a good way of documenting what has been
|
||||
taken into account, but most importantly, it provides a way to know that
|
||||
there are no *extra* implicit constraints.
|
||||
|
||||
To learn more about how to write documentation for Rust and extra features,
|
||||
please take a look at the ``rustdoc`` book at:
|
||||
|
@ -305,7 +305,7 @@ If GDB/Binutils is used and Rust symbols are not getting demangled, the reason
|
||||
is the toolchain does not support Rust's new v0 mangling scheme yet.
|
||||
There are a few ways out:
|
||||
|
||||
- Install a newer release (GDB >= 10.2, Binutils >= 2.36).
|
||||
- Install a newer release (GDB >= 10.2, Binutils >= 2.36).
|
||||
|
||||
- Some versions of GDB (e.g. vanilla GDB 10.1) are able to use
|
||||
the pre-demangled names embedded in the debug info (``CONFIG_DEBUG_INFO``).
|
||||
- Some versions of GDB (e.g. vanilla GDB 10.1) are able to use
|
||||
the pre-demangled names embedded in the debug info (``CONFIG_DEBUG_INFO``).
|
||||
|
1
Makefile
1
Makefile
@ -445,6 +445,7 @@ KBUILD_USERLDFLAGS := $(USERLDFLAGS)
|
||||
# host programs.
|
||||
export rust_common_flags := --edition=2021 \
|
||||
-Zbinary_dep_depinfo=y \
|
||||
-Astable_features \
|
||||
-Dunsafe_op_in_unsafe_fn \
|
||||
-Dnon_ascii_idents \
|
||||
-Wrust_2018_idioms \
|
||||
|
@ -305,7 +305,7 @@ $(obj)/bindings/bindings_helpers_generated.rs: $(src)/helpers.c FORCE
|
||||
quiet_cmd_exports = EXPORTS $@
|
||||
cmd_exports = \
|
||||
$(NM) -p --defined-only $< \
|
||||
| awk '/ (T|R|D) / {printf "EXPORT_SYMBOL_RUST_GPL(%s);\n",$$3}' > $@
|
||||
| awk '/ (T|R|D|B) / {printf "EXPORT_SYMBOL_RUST_GPL(%s);\n",$$3}' > $@
|
||||
|
||||
$(obj)/exports_core_generated.h: $(obj)/core.o FORCE
|
||||
$(call if_changed,exports)
|
||||
|
@ -21,8 +21,10 @@ pub trait BoxExt<T>: Sized {
|
||||
|
||||
impl<T> BoxExt<T> for Box<T> {
|
||||
fn new(x: T, flags: Flags) -> Result<Self, AllocError> {
|
||||
let b = <Self as BoxExt<_>>::new_uninit(flags)?;
|
||||
Ok(Box::write(b, x))
|
||||
let mut b = <Self as BoxExt<_>>::new_uninit(flags)?;
|
||||
b.write(x);
|
||||
// SAFETY: We just wrote to it.
|
||||
Ok(unsafe { b.assume_init() })
|
||||
}
|
||||
|
||||
#[cfg(any(test, testlib))]
|
||||
|
@ -6,8 +6,8 @@
|
||||
//! C header: [`include/linux/blk_mq.h`](srctree/include/linux/blk_mq.h)
|
||||
|
||||
use crate::block::mq::{raw_writer::RawWriter, Operations, TagSet};
|
||||
use crate::error;
|
||||
use crate::{bindings, error::from_err_ptr, error::Result, sync::Arc};
|
||||
use crate::{error, static_lock_class};
|
||||
use core::fmt::{self, Write};
|
||||
|
||||
/// A builder for [`GenDisk`].
|
||||
@ -93,8 +93,6 @@ impl GenDiskBuilder {
|
||||
name: fmt::Arguments<'_>,
|
||||
tagset: Arc<TagSet<T>>,
|
||||
) -> Result<GenDisk<T>> {
|
||||
let lock_class_key = crate::sync::LockClassKey::new();
|
||||
|
||||
// SAFETY: `bindings::queue_limits` contain only fields that are valid when zeroed.
|
||||
let mut lim: bindings::queue_limits = unsafe { core::mem::zeroed() };
|
||||
|
||||
@ -110,7 +108,7 @@ impl GenDiskBuilder {
|
||||
tagset.raw_tag_set(),
|
||||
&mut lim,
|
||||
core::ptr::null_mut(),
|
||||
lock_class_key.as_ptr(),
|
||||
static_lock_class!().as_ptr(),
|
||||
)
|
||||
})?;
|
||||
|
||||
|
@ -145,7 +145,7 @@
|
||||
//! }
|
||||
//! }
|
||||
//! // Implement the internal `PinData` trait that marks the pin-data struct as a pin-data
|
||||
//! // struct. This is important to ensure that no user can implement a rouge `__pin_data`
|
||||
//! // struct. This is important to ensure that no user can implement a rogue `__pin_data`
|
||||
//! // function without using `unsafe`.
|
||||
//! unsafe impl<T> ::kernel::init::__internal::PinData for __ThePinData<T> {
|
||||
//! type Datee = Bar<T>;
|
||||
@ -156,7 +156,7 @@
|
||||
//! // case no such fields exist, hence this is almost empty. The two phantomdata fields exist
|
||||
//! // for two reasons:
|
||||
//! // - `__phantom`: every generic must be used, since we cannot really know which generics
|
||||
//! // are used, we declere all and then use everything here once.
|
||||
//! // are used, we declare all and then use everything here once.
|
||||
//! // - `__phantom_pin`: uses the `'__pin` lifetime and ensures that this struct is invariant
|
||||
//! // over it. The lifetime is needed to work around the limitation that trait bounds must
|
||||
//! // not be trivial, e.g. the user has a `#[pin] PhantomPinned` field -- this is
|
||||
|
@ -491,7 +491,7 @@ impl<T: Driver> Adapter<T> {
|
||||
pub struct DriverVTable(Opaque<bindings::phy_driver>);
|
||||
|
||||
// SAFETY: `DriverVTable` doesn't expose any &self method to access internal data, so it's safe to
|
||||
// share `&DriverVTable` across execution context boundries.
|
||||
// share `&DriverVTable` across execution context boundaries.
|
||||
unsafe impl Sync for DriverVTable {}
|
||||
|
||||
/// Creates a [`DriverVTable`] instance from [`Driver`].
|
||||
|
Loading…
Reference in New Issue
Block a user