Add `Unsupported` to `std::io::ErrorKind` #78880

CDirkx · 2020-11-08T15:02:30Z

I noticed a significant portion of the uses of ErrorKind::Other in std is for unsupported operations.
The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just "an unspecified error occurred", which is why I am proposing to add the variant Unsupported to std::io::ErrorKind.

Implementation:

The following variant will be added to std::io::ErrorKind:

/// This operation is unsupported on this platform.
Unsupported

std::io::ErrorKind::Unsupported is an error returned when a given operation is not supported on a platform, and will thus never succeed; there is no way for the software to recover. It will be used instead of Other where appropriate, e.g. on wasm for file and network operations.

decode_error_kind will be updated to decode operating system errors to Unsupported:

Unix and VxWorks: libc::ENOSYS
Windows: c::ERROR_CALL_NOT_IMPLEMENTED
WASI: wasi::ERRNO_NOSYS

Stability:
This changes the kind of error returned by some functions on some platforms, which I think is not covered by the stability guarantees of the std? User code could depend on this behavior, expecting ErrorKind::Other, however the docs already mention:

Errors that are Other now may move to a different or a new ErrorKind variant in the future. It is not recommended to match an error against Other and to expect any additional characteristics, e.g., a specific Error::raw_os_error return value.

The most recent variant added to ErrorKind was UnexpectedEof in 1.6.0 (almost 5 years ago), but ErrorKind is marked as #[non_exhaustive] and the docs warn about exhaustively matching on it, so adding a new variant per se should not be a breaking change.

The variant Unsupported itself could be marked as #[unstable], however, because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.

rust-highfive · 2020-11-08T15:02:33Z

r? @shepmaster

(rust_highfive has picked a reviewer for you, use r? to override)

library/std/src/sys/unsupported/os.rs

scottmcm · 2020-11-08T19:07:00Z

cc @rust-lang/libs explicitly for this -- this might need to go in insta-stable, since while the variant can be marked unstable, the change to stop emitting the previous one would not be feature-gated.

the8472 · 2020-11-08T22:00:18Z

Should decode_error_kind be extended to translate any of libc::{ENOSYS,ENOTSUP,EOPNOTSUPP} to this ErrorKind?

CDirkx · 2020-11-08T23:29:24Z

I updated decode_error_kind to support NotSupported on various platforms:

Unix and VxWorks: libc::{ENOSYS, ENOTSUP, EOPNOTSUPP}
Windows: c::{ERROR_CALL_NOT_IMPLEMENTED, E_NOTIMPL}
CloudABI: abi::errno::{NOSYS, NOTSUP} (has no OPNOTSUPP)
WASI: wasi::{ERRNO_NOSYS, ERRNO_NOSUP} (has no OPNOTSUPP)
Hermit: (has hard coded error numbers, I could not find a relevant error number)
SGX: (has no equivalent error in fortanix_sgx_abi::Error)

I didn't include errors like EAFNOSUPPORT (address family not supported) and EPROTONOSUPPORT (protocol not supported) for now.

The implementation for unsupported targets is currently:

pub fn decode_error_kind(_code: i32) -> crate::io::ErrorKind {
    crate::io::ErrorKind::Other
}

which still seems fine to me.

m-ou-se · 2020-11-09T12:00:48Z

user code could depend on this behavior, expecting ErrorKind::Other

The documentation fortunately already notes that these kind of changes might happen in the future:

Errors that are Other now may move to a different or a new ErrorKind variant in the future. It is not recommended to match an error against Other and to expect any additional characteristics, e.g., a specific Error::raw_os_error return value.

(In hindsight it might have been better if matching 'other' errors against ErrorKind::Other was not possible. E.g. by using an unstable/doc(hidden) variant for those. But I guess it's too late for that now.)

I'm not sure if adding an #[unstable] variant to this stable enum is a good idea. Especially as these errors used a #[stable] variant before, like @scottmcm mentioned.

CloudABI: abi::errno::{NOSYS, NOTSUP} (has no OPNOTSUPP)

Feel free to ignore CloudABI, as that platform itself will be NOTSUP soon: #78439

KodrAus · 2020-11-09T20:55:55Z

I can see the value in wanting to check whether or not an IO operation is supported so you can fallback to alternatives.

I also think we should consider marking this as insta-stable if we want to add it. In either case I think an FCP would probably be a good idea before we land it.

CDirkx · 2020-11-13T18:45:50Z

I have updated the PR to immediately stabilize NotSupported and updated the description to include the information inthis thread.

shepmaster · 2020-11-17T02:38:29Z

r? @KodrAus

KodrAus · 2021-01-14T02:23:55Z

@rfcbot fcp merge

This proposes adding a NotSupported variant to io::ErrorKind that's used when an operation isn't supported. Callers may want to try falling back to alternatives or bubble up.

rfcbot · 2021-01-14T02:23:57Z

Team member @KodrAus has proposed to merge this. The next step is review by the rest of the tagged team members:

Concerns:

~~EOPNOTSUPP~~ resolved by Add Unsupported to std::io::ErrorKind #78880 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

CDirkx · 2021-04-18T07:31:26Z

Rebased and fixed the clippy error, should be ready to try merging again.

jyn514 · 2021-04-18T13:50:27Z

@bors r=joshtriplett

bors · 2021-04-18T13:50:28Z

📌 Commit 5b5afae has been approved by joshtriplett

Add `Unsupported` to `std::io::ErrorKind` I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations. The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just "an unspecified error occurred", which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`. **Implementation**: The following variant will be added to `std::io::ErrorKind`: ```rust /// This operation is unsupported on this platform. Unsupported ``` `std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform, and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate, e.g. on wasm for file and network operations. `decode_error_kind` will be updated to decode operating system errors to `Unsupported`: - Unix and VxWorks: `libc::ENOSYS` - Windows: `c::ERROR_CALL_NOT_IMPLEMENTED` - WASI: `wasi::ERRNO_NOSYS` **Stability**: This changes the kind of error returned by some functions on some platforms, which I think is not covered by the stability guarantees of the std? User code could depend on this behavior, expecting `ErrorKind::Other`, however the docs already mention: > Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics, e.g., a specific `Error::raw_os_error` return value. The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago), but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it, so adding a new variant per se should not be a breaking change. The variant `Unsupported` itself could be marked as `#[unstable]`, however, because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.

bors · 2021-04-18T18:52:44Z

⌛ Testing commit 5b5afae with merge 0052f444a7935147d31baa80099dbdfb1140255d...

rust-log-analyzer · 2021-04-18T19:57:20Z

The job dist-x86_64-apple-alt failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

      Memory: 14 GB
      Boot ROM Version: VMW71.00V.13989454.B64.1906190538
      Apple ROM Info: [MS_VM_CERT/SHA1/27d66596a61c48dd3dc7216fd715126e33f59ae7]Welcome to the Virtual Machine
      SMC Version (system): 2.8f0
      Serial Number (system): VMdSnO8Wr7RX

hw.ncpu: 3
hw.byteorder: 1234
hw.memsize: 15032385536

bors · 2021-04-18T19:58:02Z

💔 Test failed - checks-actions

jyn514 · 2021-04-18T19:58:42Z

error: failed to download from `https://crates.io/api/v1/crates/minifier/0.0.39/download`
failed to run: /Users/runner/work/rust/rust/build/bootstrap/debug/bootstrap dist

Caused by:
  failed to get 200 response from `https://crates.io/api/v1/crates/minifier/0.0.39/download`, got 503

@bors retry

bors · 2021-04-18T20:03:58Z

⌛ Testing commit 5b5afae with merge 5a4ab26...

bors · 2021-04-18T22:45:03Z

☀️ Test successful - checks-actions
Approved by: joshtriplett
Pushing 5a4ab26 to master...

Add `Unsupported` to `std::io::ErrorKind` I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations. The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just "an unspecified error occurred", which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`. **Implementation**: The following variant will be added to `std::io::ErrorKind`: ```rust /// This operation is unsupported on this platform. Unsupported ``` `std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform, and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate, e.g. on wasm for file and network operations. `decode_error_kind` will be updated to decode operating system errors to `Unsupported`: - Unix and VxWorks: `libc::ENOSYS` - Windows: `c::ERROR_CALL_NOT_IMPLEMENTED` - WASI: `wasi::ERRNO_NOSYS` **Stability**: This changes the kind of error returned by some functions on some platforms, which I think is not covered by the stability guarantees of the std? User code could depend on this behavior, expecting `ErrorKind::Other`, however the docs already mention: > Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics, e.g., a specific `Error::raw_os_error` return value. The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago), but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it, so adding a new variant per se should not be a breaking change. The variant `Unsupported` itself could be marked as `#[unstable]`, however, because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.

rust-highfive assigned shepmaster Nov 8, 2020

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 8, 2020

CDirkx mentioned this pull request Nov 8, 2020

Tracking Issue for #![feature(unsupported_error)] #78877

Closed

jyn514 added A-io Area: `std::io`, `std::fs`, `std::net` and `std::path` T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Nov 8, 2020

jyn514 reviewed Nov 8, 2020

View reviewed changes

library/std/src/sys/unsupported/os.rs Outdated Show resolved Hide resolved

CDirkx force-pushed the not_supported branch from 1caa84e to 178a527 Compare November 8, 2020 23:12

CDirkx force-pushed the not_supported branch from 178a527 to 90d22bc Compare November 13, 2020 18:19

rust-highfive assigned KodrAus and unassigned shepmaster Nov 17, 2020

This comment has been minimized.

Sign in to view

CDirkx force-pushed the not_supported branch from 90d22bc to 1918e9a Compare November 20, 2020 04:47

This comment has been minimized.

Sign in to view

CDirkx force-pushed the not_supported branch from 1918e9a to dd62689 Compare November 20, 2020 05:18

crlf0710 added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 11, 2020

JohnCSimon added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 11, 2021

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Jan 14, 2021

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 18, 2021

GuillaumeGomez mentioned this pull request Apr 18, 2021

Rollup of 5 pull requests #84302

Closed

GuillaumeGomez mentioned this pull request Apr 18, 2021

Rollup of 4 pull requests #84303

Closed

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Apr 18, 2021

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 18, 2021

bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 18, 2021

bors merged commit 5a4ab26 into rust-lang:master Apr 18, 2021

rustbot added this to the 1.53.0 milestone Apr 18, 2021

CDirkx deleted the not_supported branch April 18, 2021 22:46

bors mentioned this pull request Apr 18, 2021

Move sys::vxworks code to sys::unix #84119

Merged

cuviper mentioned this pull request Feb 28, 2024

handle unavailable creation time as io::ErrorKind::Unsupported #121691

Merged

saethlin mentioned this pull request May 18, 2024

Use throw_unsup_format! instead of returning ENOTSUP in the mmap shim rust-lang/miri#3610

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add `Unsupported` to `std::io::ErrorKind` #78880

Add `Unsupported` to `std::io::ErrorKind` #78880

CDirkx commented Nov 8, 2020 •

edited

Loading

rust-highfive commented Nov 8, 2020

scottmcm commented Nov 8, 2020

the8472 commented Nov 8, 2020

CDirkx commented Nov 8, 2020 •

edited

Loading

m-ou-se commented Nov 9, 2020

KodrAus commented Nov 9, 2020

CDirkx commented Nov 13, 2020

shepmaster commented Nov 17, 2020

This comment has been minimized.

This comment has been minimized.

KodrAus commented Jan 14, 2021

rfcbot commented Jan 14, 2021 •

edited

Loading

CDirkx commented Apr 18, 2021

jyn514 commented Apr 18, 2021

bors commented Apr 18, 2021

bors commented Apr 18, 2021

rust-log-analyzer commented Apr 18, 2021

bors commented Apr 18, 2021

jyn514 commented Apr 18, 2021

bors commented Apr 18, 2021

bors commented Apr 18, 2021

Add Unsupported to std::io::ErrorKind #78880

Add Unsupported to std::io::ErrorKind #78880

Conversation

CDirkx commented Nov 8, 2020 • edited Loading

rust-highfive commented Nov 8, 2020

scottmcm commented Nov 8, 2020

the8472 commented Nov 8, 2020

CDirkx commented Nov 8, 2020 • edited Loading

m-ou-se commented Nov 9, 2020

KodrAus commented Nov 9, 2020

CDirkx commented Nov 13, 2020

shepmaster commented Nov 17, 2020

This comment has been minimized.

This comment has been minimized.

KodrAus commented Jan 14, 2021

rfcbot commented Jan 14, 2021 • edited Loading

CDirkx commented Apr 18, 2021

jyn514 commented Apr 18, 2021

bors commented Apr 18, 2021

bors commented Apr 18, 2021

rust-log-analyzer commented Apr 18, 2021

bors commented Apr 18, 2021

jyn514 commented Apr 18, 2021

bors commented Apr 18, 2021

bors commented Apr 18, 2021

Add `Unsupported` to `std::io::ErrorKind` #78880

Add `Unsupported` to `std::io::ErrorKind` #78880

CDirkx commented Nov 8, 2020 •

edited

Loading

CDirkx commented Nov 8, 2020 •

edited

Loading

rfcbot commented Jan 14, 2021 •

edited

Loading