0
0
mirror of https://github.com/rust-lang/rust.git synced 2024-12-01 13:18:54 +01:00
rust/library
bors 5a4ab26459 Auto merge of #78880 - CDirkx:not_supported, r=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.
2021-04-18 20:03:54 +00:00
..
alloc Rollup merge of #84145 - vojtechkral:vecdeque-binary-search, r=m-ou-se 2021-04-16 14:08:32 +02:00
backtrace@710fc18ddc
core Auto merge of #84207 - SimonSapin:deprecate-core-raw, r=dtolnay 2021-04-18 07:23:54 +00:00
panic_abort android: set abort message 2021-04-09 15:33:43 +02:00
panic_unwind
proc_macro
profiler_builtins
rtstartup
rustc-std-workspace-alloc
rustc-std-workspace-core
rustc-std-workspace-std
std Auto merge of #78880 - CDirkx:not_supported, r=joshtriplett 2021-04-18 20:03:54 +00:00
stdarch@19f5459dd0 Update stdarch submodule (to before it switched to const generics) 2021-04-12 09:39:04 -04:00
term
test Auto merge of #82300 - andersk:libtest-id, r=Amanieu 2021-04-12 13:30:30 +00:00
unwind