From 43ae1871a8b357c980c180b733f179842c80eccf Mon Sep 17 00:00:00 2001 From: Lokathor Date: Tue, 7 May 2024 18:08:36 -0600 Subject: [PATCH 1/9] Some Result combinations work like an Option. --- core/src/result.rs | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/core/src/result.rs b/core/src/result.rs index b2b627fe6a9cc..16c97284104d4 100644 --- a/core/src/result.rs +++ b/core/src/result.rs @@ -224,6 +224,21 @@ //! [`Err(E)`]: Err //! [io::Error]: ../../std/io/struct.Error.html "io::Error" //! +//! # Representation +//! +//! In some cases, [`Result`] will gain the same size, alignment, and ABI +//! guarantees as [`Option`] has. One of either the `T` or `E` type must be a +//! type that qualifies for `Option` guarantees, and the *other* type must meet +//! all of the following conditions: +//! * Is a zero-sized type with alignment 1 (a "1-ZST"). +//! * Has no fields. +//! * Does not have the #[non_exhaustive] attribute. +//! +//! For example, `Result` or `Result<(), NonZeroI32>` would both +//! have the same guarantees as `Option`. The only difference is the +//! implied semantics: `Result` is "a non-zero success value" +//! while `Result<(), NonZeroI32>` is "a non-zero error value". +//! //! # Method overview //! //! In addition to working with pattern matching, [`Result`] provides a From 50d5af4470130e1a52f193dd0012b87eda4376ef Mon Sep 17 00:00:00 2001 From: Lokathor Date: Tue, 7 May 2024 18:35:00 -0600 Subject: [PATCH 2/9] use teletype on the attribute name --- core/src/result.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/core/src/result.rs b/core/src/result.rs index 16c97284104d4..b82351ea1fa3c 100644 --- a/core/src/result.rs +++ b/core/src/result.rs @@ -232,7 +232,7 @@ //! all of the following conditions: //! * Is a zero-sized type with alignment 1 (a "1-ZST"). //! * Has no fields. -//! * Does not have the #[non_exhaustive] attribute. +//! * Does not have the `#[non_exhaustive]` attribute. //! //! For example, `Result` or `Result<(), NonZeroI32>` would both //! have the same guarantees as `Option`. The only difference is the From f84d57f6cc336234e8f0ec224c2c78301020ff9d Mon Sep 17 00:00:00 2001 From: Lokathor Date: Mon, 13 May 2024 10:36:42 -0600 Subject: [PATCH 3/9] Don't use `T` with both Result and Option, improve explanation. --- core/src/result.rs | 137 +++++++++++++++++++++++---------------------- 1 file changed, 70 insertions(+), 67 deletions(-) diff --git a/core/src/result.rs b/core/src/result.rs index b82351ea1fa3c..6a77f9f63a88d 100644 --- a/core/src/result.rs +++ b/core/src/result.rs @@ -1,9 +1,9 @@ //! Error handling with the `Result` type. //! //! [`Result`][`Result`] is the type used for returning and propagating -//! errors. It is an enum with the variants, [`Ok(T)`], representing -//! success and containing a value, and [`Err(E)`], representing error -//! and containing an error value. +//! errors. It is an enum with the variants, [`Ok(T)`], representing success and +//! containing a value, and [`Err(E)`], representing error and containing an +//! error value. //! //! ``` //! # #[allow(dead_code)] @@ -13,12 +13,11 @@ //! } //! ``` //! -//! Functions return [`Result`] whenever errors are expected and -//! recoverable. In the `std` crate, [`Result`] is most prominently used -//! for [I/O](../../std/io/index.html). +//! Functions return [`Result`] whenever errors are expected and recoverable. In +//! the `std` crate, [`Result`] is most prominently used for +//! [I/O](../../std/io/index.html). //! -//! A simple function returning [`Result`] might be -//! defined and used like so: +//! A simple function returning [`Result`] might be defined and used like so: //! //! ``` //! #[derive(Debug)] @@ -40,9 +39,9 @@ //! } //! ``` //! -//! Pattern matching on [`Result`]s is clear and straightforward for -//! simple cases, but [`Result`] comes with some convenience methods -//! that make working with it more succinct. +//! Pattern matching on [`Result`]s is clear and straightforward for simple +//! cases, but [`Result`] comes with some convenience methods that make working +//! with it more succinct. //! //! ``` //! let good_result: Result = Ok(10); @@ -68,16 +67,15 @@ //! //! # Results must be used //! -//! A common problem with using return values to indicate errors is -//! that it is easy to ignore the return value, thus failing to handle -//! the error. [`Result`] is annotated with the `#[must_use]` attribute, -//! which will cause the compiler to issue a warning when a Result -//! value is ignored. This makes [`Result`] especially useful with -//! functions that may encounter errors but don't otherwise return a -//! useful value. +//! A common problem with using return values to indicate errors is that it is +//! easy to ignore the return value, thus failing to handle the error. +//! [`Result`] is annotated with the `#[must_use]` attribute, which will cause +//! the compiler to issue a warning when a Result value is ignored. This makes +//! [`Result`] especially useful with functions that may encounter errors but +//! don't otherwise return a useful value. //! -//! Consider the [`write_all`] method defined for I/O types -//! by the [`Write`] trait: +//! Consider the [`write_all`] method defined for I/O types by the [`Write`] +//! trait: //! //! ``` //! use std::io; @@ -87,12 +85,11 @@ //! } //! ``` //! -//! *Note: The actual definition of [`Write`] uses [`io::Result`], which -//! is just a synonym for [Result].* +//! *Note: The actual definition of [`Write`] uses [`io::Result`], which is just +//! a synonym for [Result].* //! -//! This method doesn't produce a value, but the write may -//! fail. It's crucial to handle the error case, and *not* write -//! something like this: +//! This method doesn't produce a value, but the write may fail. It's crucial to +//! handle the error case, and *not* write something like this: //! //! ```no_run //! # #![allow(unused_must_use)] // \o/ @@ -105,12 +102,12 @@ //! file.write_all(b"important message"); //! ``` //! -//! If you *do* write that in Rust, the compiler will give you a -//! warning (by default, controlled by the `unused_must_use` lint). +//! If you *do* write that in Rust, the compiler will give you a warning (by +//! default, controlled by the `unused_must_use` lint). //! -//! You might instead, if you don't want to handle the error, simply -//! assert success with [`expect`]. This will panic if the -//! write fails, providing a marginally useful message indicating why: +//! You might instead, if you don't want to handle the error, simply assert +//! success with [`expect`]. This will panic if the write fails, providing a +//! marginally useful message indicating why: //! //! ```no_run //! use std::fs::File; @@ -145,10 +142,9 @@ //! //! # The question mark operator, `?` //! -//! When writing code that calls many functions that return the -//! [`Result`] type, the error handling can be tedious. The question mark -//! operator, [`?`], hides some of the boilerplate of propagating errors -//! up the call stack. +//! When writing code that calls many functions that return the [`Result`] type, +//! the error handling can be tedious. The question mark operator, [`?`], hides +//! some of the boilerplate of propagating errors up the call stack. //! //! It replaces this: //! @@ -209,15 +205,17 @@ //! //! *It's much nicer!* //! -//! Ending the expression with [`?`] will result in the [`Ok`]'s unwrapped value, unless the result -//! is [`Err`], in which case [`Err`] is returned early from the enclosing function. +//! Ending the expression with [`?`] will result in the [`Ok`]'s unwrapped +//! value, unless the result is [`Err`], in which case [`Err`] is returned early +//! from the enclosing function. //! -//! [`?`] can be used in functions that return [`Result`] because of the -//! early return of [`Err`] that it provides. +//! [`?`] can be used in functions that return [`Result`] because of the early +//! return of [`Err`] that it provides. //! //! [`expect`]: Result::expect //! [`Write`]: ../../std/io/trait.Write.html "io::Write" -//! [`write_all`]: ../../std/io/trait.Write.html#method.write_all "io::Write::write_all" +//! [`write_all`]: ../../std/io/trait.Write.html#method.write_all +//! "io::Write::write_all" //! [`io::Result`]: ../../std/io/type.Result.html "io::Result" //! [`?`]: crate::ops::Try //! [`Ok(T)`]: Ok @@ -227,27 +225,33 @@ //! # Representation //! //! In some cases, [`Result`] will gain the same size, alignment, and ABI -//! guarantees as [`Option`] has. One of either the `T` or `E` type must be a -//! type that qualifies for `Option` guarantees, and the *other* type must meet -//! all of the following conditions: +//! guarantees as [`Option`] has. One of either the `T` or `E` type must be a +//! type that qualifies for the `Option` [representation guarantees][opt-rep], +//! and the *other* type must meet all of the following conditions: //! * Is a zero-sized type with alignment 1 (a "1-ZST"). //! * Has no fields. //! * Does not have the `#[non_exhaustive]` attribute. //! -//! For example, `Result` or `Result<(), NonZeroI32>` would both -//! have the same guarantees as `Option`. The only difference is the -//! implied semantics: `Result` is "a non-zero success value" -//! while `Result<(), NonZeroI32>` is "a non-zero error value". +//! For example, `NonZeroI32` qualifies for the `Option` representation +//! guarantees, and `()` is a zero-sized type with alignment 1, no fields, and +//! it isn't `non_exhaustive`. This means that both `Result` and +//! `Result<(), NonZeroI32>` have the same size, alignment, and ABI guarantees +//! as `Option`. The only difference is the implied semantics: +//! * `Option` is "a non-zero i32 might be present" +//! * `Result` is "a non-zero i32 success result, if any" +//! * `Result<(), NonZeroI32>` is "a non-zero i32 error result, if any" +//! +//! [opt-rep]: ../option/index.html#representation "Option Representation" //! //! # Method overview //! -//! In addition to working with pattern matching, [`Result`] provides a -//! wide variety of different methods. +//! In addition to working with pattern matching, [`Result`] provides a wide +//! variety of different methods. //! //! ## Querying the variant //! -//! The [`is_ok`] and [`is_err`] methods return [`true`] if the [`Result`] -//! is [`Ok`] or [`Err`], respectively. +//! The [`is_ok`] and [`is_err`] methods return [`true`] if the [`Result`] is +//! [`Ok`] or [`Err`], respectively. //! //! [`is_err`]: Result::is_err //! [`is_ok`]: Result::is_ok @@ -257,8 +261,8 @@ //! * [`as_ref`] converts from `&Result` to `Result<&T, &E>` //! * [`as_mut`] converts from `&mut Result` to `Result<&mut T, &mut E>` //! * [`as_deref`] converts from `&Result` to `Result<&T::Target, &E>` -//! * [`as_deref_mut`] converts from `&mut Result` to -//! `Result<&mut T::Target, &mut E>` +//! * [`as_deref_mut`] converts from `&mut Result` to `Result<&mut +//! T::Target, &mut E>` //! //! [`as_deref`]: Result::as_deref //! [`as_deref_mut`]: Result::as_deref_mut @@ -267,19 +271,18 @@ //! //! ## Extracting contained values //! -//! These methods extract the contained value in a [`Result`] when it -//! is the [`Ok`] variant. If the [`Result`] is [`Err`]: +//! These methods extract the contained value in a [`Result`] when it is +//! the [`Ok`] variant. If the [`Result`] is [`Err`]: //! //! * [`expect`] panics with a provided custom message //! * [`unwrap`] panics with a generic message //! * [`unwrap_or`] returns the provided default value -//! * [`unwrap_or_default`] returns the default value of the type `T` -//! (which must implement the [`Default`] trait) -//! * [`unwrap_or_else`] returns the result of evaluating the provided -//! function +//! * [`unwrap_or_default`] returns the default value of the type `T` (which +//! must implement the [`Default`] trait) +//! * [`unwrap_or_else`] returns the result of evaluating the provided function //! -//! The panicking methods [`expect`] and [`unwrap`] require `E` to -//! implement the [`Debug`] trait. +//! The panicking methods [`expect`] and [`unwrap`] require `E` to implement the +//! [`Debug`] trait. //! //! [`Debug`]: crate::fmt::Debug //! [`expect`]: Result::expect @@ -288,9 +291,9 @@ //! [`unwrap_or_default`]: Result::unwrap_or_default //! [`unwrap_or_else`]: Result::unwrap_or_else //! -//! These methods extract the contained value in a [`Result`] when it -//! is the [`Err`] variant. They require `T` to implement the [`Debug`] -//! trait. If the [`Result`] is [`Ok`]: +//! These methods extract the contained value in a [`Result`] when it is +//! the [`Err`] variant. They require `T` to implement the [`Debug`] trait. If +//! the [`Result`] is [`Ok`]: //! //! * [`expect_err`] panics with a provided custom message //! * [`unwrap_err`] panics with a generic message @@ -305,10 +308,10 @@ //! //! * [`err`][Result::err] transforms [`Result`] into [`Option`], //! mapping [`Err(e)`] to [`Some(e)`] and [`Ok(v)`] to [`None`] -//! * [`ok`][Result::ok] transforms [`Result`] into [`Option`], -//! mapping [`Ok(v)`] to [`Some(v)`] and [`Err(e)`] to [`None`] -//! * [`transpose`] transposes a [`Result`] of an [`Option`] into an -//! [`Option`] of a [`Result`] +//! * [`ok`][Result::ok] transforms [`Result`] into [`Option`], mapping +//! [`Ok(v)`] to [`Some(v)`] and [`Err(e)`] to [`None`] +//! * [`transpose`] transposes a [`Result`] of an [`Option`] into an [`Option`] +//! of a [`Result`] //! // Do NOT add link reference definitions for `err` or `ok`, because they // will generate numerous incorrect URLs for `Err` and `Ok` elsewhere, due From 9677b7057a8f8de18c66c5134b6d132259d74422 Mon Sep 17 00:00:00 2001 From: Lokathor Date: Sat, 25 May 2024 15:41:18 -0600 Subject: [PATCH 4/9] revert to the inconsistent paragraph wrapping. --- core/src/result.rs | 107 +++++++++++++++++++++++---------------------- 1 file changed, 55 insertions(+), 52 deletions(-) diff --git a/core/src/result.rs b/core/src/result.rs index 6a77f9f63a88d..77c4ef957ac52 100644 --- a/core/src/result.rs +++ b/core/src/result.rs @@ -2,8 +2,8 @@ //! //! [`Result`][`Result`] is the type used for returning and propagating //! errors. It is an enum with the variants, [`Ok(T)`], representing success and -//! containing a value, and [`Err(E)`], representing error and containing an -//! error value. +//! success and containing a value, and [`Err(E)`], representing error +//! and containing an error value. //! //! ``` //! # #[allow(dead_code)] @@ -14,10 +14,11 @@ //! ``` //! //! Functions return [`Result`] whenever errors are expected and recoverable. In -//! the `std` crate, [`Result`] is most prominently used for -//! [I/O](../../std/io/index.html). +//! recoverable. In the `std` crate, [`Result`] is most prominently used +//! for [I/O](../../std/io/index.html). //! -//! A simple function returning [`Result`] might be defined and used like so: +//! A simple function returning [`Result`] might be +//! defined and used like so: //! //! ``` //! #[derive(Debug)] @@ -40,8 +41,8 @@ //! ``` //! //! Pattern matching on [`Result`]s is clear and straightforward for simple -//! cases, but [`Result`] comes with some convenience methods that make working -//! with it more succinct. +//! simple cases, but [`Result`] comes with some convenience methods +//! that make working with it more succinct. //! //! ``` //! let good_result: Result = Ok(10); @@ -67,15 +68,16 @@ //! //! # Results must be used //! -//! A common problem with using return values to indicate errors is that it is -//! easy to ignore the return value, thus failing to handle the error. -//! [`Result`] is annotated with the `#[must_use]` attribute, which will cause -//! the compiler to issue a warning when a Result value is ignored. This makes -//! [`Result`] especially useful with functions that may encounter errors but -//! don't otherwise return a useful value. +//! A common problem with using return values to indicate errors is +//! that it is easy to ignore the return value, thus failing to handle +//! the error. [`Result`] is annotated with the `#[must_use]` attribute, +//! which will cause the compiler to issue a warning when a Result +//! value is ignored. This makes [`Result`] especially useful with +//! functions that may encounter errors but don't otherwise return a +//! useful value. //! -//! Consider the [`write_all`] method defined for I/O types by the [`Write`] -//! trait: +//! Consider the [`write_all`] method defined for I/O types +//! by the [`Write`] trait: //! //! ``` //! use std::io; @@ -85,11 +87,12 @@ //! } //! ``` //! -//! *Note: The actual definition of [`Write`] uses [`io::Result`], which is just -//! a synonym for [Result].* +//! *Note: The actual definition of [`Write`] uses [`io::Result`], which +//! is just a synonym for [Result].* //! -//! This method doesn't produce a value, but the write may fail. It's crucial to -//! handle the error case, and *not* write something like this: +//! This method doesn't produce a value, but the write may +//! fail. It's crucial to handle the error case, and *not* write +//! something like this: //! //! ```no_run //! # #![allow(unused_must_use)] // \o/ @@ -102,12 +105,12 @@ //! file.write_all(b"important message"); //! ``` //! -//! If you *do* write that in Rust, the compiler will give you a warning (by -//! default, controlled by the `unused_must_use` lint). +//! If you *do* write that in Rust, the compiler will give you a +//! warning (by default, controlled by the `unused_must_use` lint). //! -//! You might instead, if you don't want to handle the error, simply assert -//! success with [`expect`]. This will panic if the write fails, providing a -//! marginally useful message indicating why: +//! You might instead, if you don't want to handle the error, simply +//! assert success with [`expect`]. This will panic if the +//! write fails, providing a marginally useful message indicating why: //! //! ```no_run //! use std::fs::File; @@ -142,9 +145,10 @@ //! //! # The question mark operator, `?` //! -//! When writing code that calls many functions that return the [`Result`] type, -//! the error handling can be tedious. The question mark operator, [`?`], hides -//! some of the boilerplate of propagating errors up the call stack. +//! When writing code that calls many functions that return the +//! [`Result`] type, the error handling can be tedious. The question mark +//! operator, [`?`], hides some of the boilerplate of propagating errors +//! up the call stack. //! //! It replaces this: //! @@ -205,17 +209,15 @@ //! //! *It's much nicer!* //! -//! Ending the expression with [`?`] will result in the [`Ok`]'s unwrapped -//! value, unless the result is [`Err`], in which case [`Err`] is returned early -//! from the enclosing function. +//! Ending the expression with [`?`] will result in the [`Ok`]'s unwrapped value, unless the result +//! is [`Err`], in which case [`Err`] is returned early from the enclosing function. //! -//! [`?`] can be used in functions that return [`Result`] because of the early -//! return of [`Err`] that it provides. +//! [`?`] can be used in functions that return [`Result`] because of the +//! early return of [`Err`] that it provides. //! //! [`expect`]: Result::expect //! [`Write`]: ../../std/io/trait.Write.html "io::Write" -//! [`write_all`]: ../../std/io/trait.Write.html#method.write_all -//! "io::Write::write_all" +//! [`write_all`]: ../../std/io/trait.Write.html#method.write_all "io::Write::write_all" //! [`io::Result`]: ../../std/io/type.Result.html "io::Result" //! [`?`]: crate::ops::Try //! [`Ok(T)`]: Ok @@ -250,8 +252,8 @@ //! //! ## Querying the variant //! -//! The [`is_ok`] and [`is_err`] methods return [`true`] if the [`Result`] is -//! [`Ok`] or [`Err`], respectively. +//! In addition to working with pattern matching, [`Result`] provides a +//! wide variety of different methods. //! //! [`is_err`]: Result::is_err //! [`is_ok`]: Result::is_ok @@ -261,8 +263,8 @@ //! * [`as_ref`] converts from `&Result` to `Result<&T, &E>` //! * [`as_mut`] converts from `&mut Result` to `Result<&mut T, &mut E>` //! * [`as_deref`] converts from `&Result` to `Result<&T::Target, &E>` -//! * [`as_deref_mut`] converts from `&mut Result` to `Result<&mut -//! T::Target, &mut E>` +//! * [`as_deref_mut`] converts from `&mut Result` to +//! `Result<&mut T::Target, &mut E>` //! //! [`as_deref`]: Result::as_deref //! [`as_deref_mut`]: Result::as_deref_mut @@ -271,18 +273,19 @@ //! //! ## Extracting contained values //! -//! These methods extract the contained value in a [`Result`] when it is -//! the [`Ok`] variant. If the [`Result`] is [`Err`]: +//! These methods extract the contained value in a [`Result`] when it +//! is the [`Ok`] variant. If the [`Result`] is [`Err`]: //! //! * [`expect`] panics with a provided custom message //! * [`unwrap`] panics with a generic message //! * [`unwrap_or`] returns the provided default value -//! * [`unwrap_or_default`] returns the default value of the type `T` (which -//! must implement the [`Default`] trait) -//! * [`unwrap_or_else`] returns the result of evaluating the provided function +//! * [`unwrap_or_default`] returns the default value of the type `T` +//! (which must implement the [`Default`] trait) +//! * [`unwrap_or_else`] returns the result of evaluating the provided +//! function //! -//! The panicking methods [`expect`] and [`unwrap`] require `E` to implement the -//! [`Debug`] trait. +//! The panicking methods [`expect`] and [`unwrap`] require `E` to +//! implement the [`Debug`] trait. //! //! [`Debug`]: crate::fmt::Debug //! [`expect`]: Result::expect @@ -291,9 +294,9 @@ //! [`unwrap_or_default`]: Result::unwrap_or_default //! [`unwrap_or_else`]: Result::unwrap_or_else //! -//! These methods extract the contained value in a [`Result`] when it is -//! the [`Err`] variant. They require `T` to implement the [`Debug`] trait. If -//! the [`Result`] is [`Ok`]: +//! These methods extract the contained value in a [`Result`] when it +//! is the [`Err`] variant. They require `T` to implement the [`Debug`] +//! trait. If the [`Result`] is [`Ok`]: //! //! * [`expect_err`] panics with a provided custom message //! * [`unwrap_err`] panics with a generic message @@ -308,10 +311,10 @@ //! //! * [`err`][Result::err] transforms [`Result`] into [`Option`], //! mapping [`Err(e)`] to [`Some(e)`] and [`Ok(v)`] to [`None`] -//! * [`ok`][Result::ok] transforms [`Result`] into [`Option`], mapping -//! [`Ok(v)`] to [`Some(v)`] and [`Err(e)`] to [`None`] -//! * [`transpose`] transposes a [`Result`] of an [`Option`] into an [`Option`] -//! of a [`Result`] +//! * [`ok`][Result::ok] transforms [`Result`] into [`Option`], +//! mapping [`Ok(v)`] to [`Some(v)`] and [`Err(e)`] to [`None`] +//! * [`transpose`] transposes a [`Result`] of an [`Option`] into an +//! [`Option`] of a [`Result`] //! // Do NOT add link reference definitions for `err` or `ok`, because they // will generate numerous incorrect URLs for `Err` and `Ok` elsewhere, due From 613145f6c4e46a9528f70197ad0869c2511b134d Mon Sep 17 00:00:00 2001 From: Lokathor Date: Sat, 25 May 2024 15:46:55 -0600 Subject: [PATCH 5/9] Resolve https://github.com/rust-lang/rust/pull/124870#issuecomment-2128824959 --- core/src/option.rs | 3 +++ 1 file changed, 3 insertions(+) diff --git a/core/src/option.rs b/core/src/option.rs index 1e3ed0f7c49f1..c9b3c62dc4167 100644 --- a/core/src/option.rs +++ b/core/src/option.rs @@ -137,10 +137,13 @@ //! //! [^extern_fn]: this remains true for any argument/return types and any other ABI: `extern "abi" fn` (_e.g._, `extern "system" fn`) //! +//! Under some conditions the above types `T` are also null pointer optimized when wrapped in a [`Result`][result_repr]. +//! //! [`Box`]: ../../std/boxed/struct.Box.html //! [`num::NonZero*`]: crate::num //! [`ptr::NonNull`]: crate::ptr::NonNull //! [function call ABI]: ../primitive.fn.html#abi-compatibility +//! [result_repr]: crate::result::Result#Representation //! //! This is called the "null pointer optimization" or NPO. //! From 65726c04182aaf9c0f4a2b5d544fd5829a171ad2 Mon Sep 17 00:00:00 2001 From: Lokathor Date: Sat, 25 May 2024 16:04:26 -0600 Subject: [PATCH 6/9] correct for copy paste errors when fixing wrapping. --- core/src/result.rs | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/core/src/result.rs b/core/src/result.rs index 77c4ef957ac52..b40a585699b10 100644 --- a/core/src/result.rs +++ b/core/src/result.rs @@ -13,7 +13,7 @@ //! } //! ``` //! -//! Functions return [`Result`] whenever errors are expected and recoverable. In +//! Functions return [`Result`] whenever errors are expected and //! recoverable. In the `std` crate, [`Result`] is most prominently used //! for [I/O](../../std/io/index.html). //! @@ -40,7 +40,7 @@ //! } //! ``` //! -//! Pattern matching on [`Result`]s is clear and straightforward for simple +//! Pattern matching on [`Result`]s is clear and straightforward for //! simple cases, but [`Result`] comes with some convenience methods //! that make working with it more succinct. //! @@ -247,13 +247,13 @@ //! //! # Method overview //! -//! In addition to working with pattern matching, [`Result`] provides a wide -//! variety of different methods. +//! In addition to working with pattern matching, [`Result`] provides a +//! wide variety of different methods. //! //! ## Querying the variant //! -//! In addition to working with pattern matching, [`Result`] provides a -//! wide variety of different methods. +//! The [`is_ok`] and [`is_err`] methods return [`true`] if the [`Result`] +//! is [`Ok`] or [`Err`], respectively. //! //! [`is_err`]: Result::is_err //! [`is_ok`]: Result::is_ok From 3b77f19a9a84cf2ed3262da3d3040f4ca06343d4 Mon Sep 17 00:00:00 2001 From: Lokathor Date: Sat, 25 May 2024 16:05:22 -0600 Subject: [PATCH 7/9] github showed that weird. --- core/src/result.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/core/src/result.rs b/core/src/result.rs index b40a585699b10..2954284bda796 100644 --- a/core/src/result.rs +++ b/core/src/result.rs @@ -1,7 +1,7 @@ //! Error handling with the `Result` type. //! //! [`Result`][`Result`] is the type used for returning and propagating -//! errors. It is an enum with the variants, [`Ok(T)`], representing success and +//! errors. It is an enum with the variants, [`Ok(T)`], representing //! success and containing a value, and [`Err(E)`], representing error //! and containing an error value. //! From 805f56b8e1649e01c52e69d92d4015da461ec0d5 Mon Sep 17 00:00:00 2001 From: Lokathor Date: Sat, 25 May 2024 16:46:58 -0600 Subject: [PATCH 8/9] Fix URL target, it's in the module not the type. --- core/src/option.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/core/src/option.rs b/core/src/option.rs index c9b3c62dc4167..1fb65c845aff6 100644 --- a/core/src/option.rs +++ b/core/src/option.rs @@ -143,7 +143,7 @@ //! [`num::NonZero*`]: crate::num //! [`ptr::NonNull`]: crate::ptr::NonNull //! [function call ABI]: ../primitive.fn.html#abi-compatibility -//! [result_repr]: crate::result::Result#Representation +//! [result_repr]: crate::result#Representation //! //! This is called the "null pointer optimization" or NPO. //! From a4bac2bc3471bb3a6a7797e7a93a8c9418cd867e Mon Sep 17 00:00:00 2001 From: Lokathor Date: Sat, 25 May 2024 17:44:48 -0600 Subject: [PATCH 9/9] It seems that anchor names are implicitly all lowercase --- core/src/option.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/core/src/option.rs b/core/src/option.rs index 1fb65c845aff6..9a527073602e6 100644 --- a/core/src/option.rs +++ b/core/src/option.rs @@ -143,7 +143,7 @@ //! [`num::NonZero*`]: crate::num //! [`ptr::NonNull`]: crate::ptr::NonNull //! [function call ABI]: ../primitive.fn.html#abi-compatibility -//! [result_repr]: crate::result#Representation +//! [result_repr]: crate::result#representation //! //! This is called the "null pointer optimization" or NPO. //!