From 49058142499b7112a4deaca030ad9f07a554182d Mon Sep 17 00:00:00 2001 From: Dylan DPC Date: Wed, 23 Feb 2022 03:22:23 +0100 Subject: [PATCH 1/6] add matching to errorkind --- library/std/src/io/error.rs | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/library/std/src/io/error.rs b/library/std/src/io/error.rs index 1aa6d657889..ba0b9f9f6fd 100644 --- a/library/std/src/io/error.rs +++ b/library/std/src/io/error.rs @@ -141,6 +141,14 @@ struct Custom { /// It is used with the [`io::Error`] type. /// /// [`io::Error`]: Error +/// +/// # Handling errors and matching on `ErrorKind` +/// +/// In application code, use `match` for the `ErrorKind` values you are expecting; use `_` to match +/// "all other errors". +/// +/// In comprehensive and thorough tests, you may need to cut-and-paste the current list of +/// errors from here into your test code. #[derive(Clone, Copy, Debug, Eq, Hash, Ord, PartialEq, PartialOrd)] #[stable(feature = "rust1", since = "1.0.0")] #[allow(deprecated)] From 37cbc7d1202630b6a4077a16867c3065c94d6b7a Mon Sep 17 00:00:00 2001 From: Dylan DPC Date: Wed, 23 Feb 2022 03:28:27 +0100 Subject: [PATCH 2/6] add some more summary from pr discussion --- library/std/src/io/error.rs | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/library/std/src/io/error.rs b/library/std/src/io/error.rs index ba0b9f9f6fd..e4961952d0b 100644 --- a/library/std/src/io/error.rs +++ b/library/std/src/io/error.rs @@ -147,8 +147,10 @@ struct Custom { /// In application code, use `match` for the `ErrorKind` values you are expecting; use `_` to match /// "all other errors". /// -/// In comprehensive and thorough tests, you may need to cut-and-paste the current list of -/// errors from here into your test code. +/// In comprehensive and thorough tests that want to verify that a test doesn't return any known incorrect error kind, +/// you may want to cut-and-paste the current list of errors from here into your test code. This seems counterintuitive, +/// but it will make your tests more robust. In particular, if you want to verify that your code does produce an +/// unrecognized error kind, the robust solution is to check for all the recognized error kinds and fail in those cases. #[derive(Clone, Copy, Debug, Eq, Hash, Ord, PartialEq, PartialOrd)] #[stable(feature = "rust1", since = "1.0.0")] #[allow(deprecated)] From 057dc09eaea610c5a14d0908764696d9d416d544 Mon Sep 17 00:00:00 2001 From: Dylan DPC Date: Wed, 23 Feb 2022 03:29:02 +0100 Subject: [PATCH 3/6] add some more summary from pr discussion --- library/std/src/io/error.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/library/std/src/io/error.rs b/library/std/src/io/error.rs index e4961952d0b..6adf26a35a2 100644 --- a/library/std/src/io/error.rs +++ b/library/std/src/io/error.rs @@ -147,7 +147,7 @@ struct Custom { /// In application code, use `match` for the `ErrorKind` values you are expecting; use `_` to match /// "all other errors". /// -/// In comprehensive and thorough tests that want to verify that a test doesn't return any known incorrect error kind, +/// In comprehensive and thorough tests that want to verify that a test doesn't return any known incorrect error kind, /// you may want to cut-and-paste the current list of errors from here into your test code. This seems counterintuitive, /// but it will make your tests more robust. In particular, if you want to verify that your code does produce an /// unrecognized error kind, the robust solution is to check for all the recognized error kinds and fail in those cases. From c46d9f6c89fc50dd80fb502677bc8d04e8260ed3 Mon Sep 17 00:00:00 2001 From: Dylan DPC <99973273+Dylan-DPC@users.noreply.github.com> Date: Wed, 23 Feb 2022 23:18:42 +0100 Subject: [PATCH 4/6] Update library/std/src/io/error.rs Co-authored-by: Josh Triplett --- library/std/src/io/error.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/library/std/src/io/error.rs b/library/std/src/io/error.rs index 6adf26a35a2..3df3749d676 100644 --- a/library/std/src/io/error.rs +++ b/library/std/src/io/error.rs @@ -148,7 +148,7 @@ struct Custom { /// "all other errors". /// /// In comprehensive and thorough tests that want to verify that a test doesn't return any known incorrect error kind, -/// you may want to cut-and-paste the current list of errors from here into your test code. This seems counterintuitive, +/// you may want to cut-and-paste the current full list of errors from here into your test code, and then match `_` as the correct case. This seems counterintuitive, /// but it will make your tests more robust. In particular, if you want to verify that your code does produce an /// unrecognized error kind, the robust solution is to check for all the recognized error kinds and fail in those cases. #[derive(Clone, Copy, Debug, Eq, Hash, Ord, PartialEq, PartialOrd)] From eb795c24fba3da62570e144b405d7df7cf8f9963 Mon Sep 17 00:00:00 2001 From: Dylan DPC Date: Thu, 24 Feb 2022 00:30:07 +0100 Subject: [PATCH 5/6] word wrpa --- library/std/src/io/error.rs | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/library/std/src/io/error.rs b/library/std/src/io/error.rs index 3df3749d676..a69062ee2ca 100644 --- a/library/std/src/io/error.rs +++ b/library/std/src/io/error.rs @@ -144,13 +144,16 @@ struct Custom { /// /// # Handling errors and matching on `ErrorKind` /// -/// In application code, use `match` for the `ErrorKind` values you are expecting; use `_` to match -/// "all other errors". +/// In application code, use `match` for the `ErrorKind` values you are +/// expecting; use `_` to match "all other errors". /// -/// In comprehensive and thorough tests that want to verify that a test doesn't return any known incorrect error kind, -/// you may want to cut-and-paste the current full list of errors from here into your test code, and then match `_` as the correct case. This seems counterintuitive, -/// but it will make your tests more robust. In particular, if you want to verify that your code does produce an -/// unrecognized error kind, the robust solution is to check for all the recognized error kinds and fail in those cases. +/// In comprehensive and thorough tests that want to verify that a test doesn't +/// return any known incorrect error kind, you may want to cut-and-paste the +/// current full list of errors from here into your test code, and then match +/// `_` as the correct case. This seems counterintuitive, but it will make your +/// tests more robust. In particular, if you want to verify that your code does +/// produce an unrecognized error kind, the robust solution is to check for all +/// the recognized error kinds and fail in those cases. #[derive(Clone, Copy, Debug, Eq, Hash, Ord, PartialEq, PartialOrd)] #[stable(feature = "rust1", since = "1.0.0")] #[allow(deprecated)] From 3f4b039e33f2a6da6413bac416be97c1b0738ca8 Mon Sep 17 00:00:00 2001 From: Dylan DPC Date: Thu, 24 Feb 2022 00:37:06 +0100 Subject: [PATCH 6/6] word wrpa --- library/std/src/io/error.rs | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/library/std/src/io/error.rs b/library/std/src/io/error.rs index a69062ee2ca..17e2b97545a 100644 --- a/library/std/src/io/error.rs +++ b/library/std/src/io/error.rs @@ -144,13 +144,13 @@ struct Custom { /// /// # Handling errors and matching on `ErrorKind` /// -/// In application code, use `match` for the `ErrorKind` values you are +/// In application code, use `match` for the `ErrorKind` values you are /// expecting; use `_` to match "all other errors". /// -/// In comprehensive and thorough tests that want to verify that a test doesn't -/// return any known incorrect error kind, you may want to cut-and-paste the -/// current full list of errors from here into your test code, and then match -/// `_` as the correct case. This seems counterintuitive, but it will make your +/// In comprehensive and thorough tests that want to verify that a test doesn't +/// return any known incorrect error kind, you may want to cut-and-paste the +/// current full list of errors from here into your test code, and then match +/// `_` as the correct case. This seems counterintuitive, but it will make your /// tests more robust. In particular, if you want to verify that your code does /// produce an unrecognized error kind, the robust solution is to check for all /// the recognized error kinds and fail in those cases.