Move `sys::vxworks` code to `sys::unix`
Follow-up to #77666, `sys::vxworks` is almost identical to `sys::unix`, the only differences are the `rand`, `thread_local_dtor`, and `process` implementation. Since `vxworks` is `target_family = unix` anyway, there is no reason for the code not to live inside of `sys::unix` like all the other unix-OSes.
e41f378f82/compiler/rustc_target/src/spec/vxworks_base.rs (L12)
``@rustbot`` label: +T-libs-impl
Replace all `fmt.pad` with `debug_struct`
This replaces any occurrence of:
- `f.pad("X")` with `f.debug_struct("X").finish()`
- `f.pad("X { .. }")` with `f.debug_struct("X").finish_non_exhaustive()`
This is in line with existing formatting code such as
1255053067/library/std/src/sync/mpsc/mod.rs (L1470-L1475)
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.
Deprecate the core::raw / std::raw module
It only contains the `TraitObject` struct which exposes components of wide pointer. Pointer metadata APIs are designed to replace this: https://github.com/rust-lang/rust/issues/81513
This commit adds a variant of the `thread_local!` macro as a new
`thread_local_const_init!` macro which requires that the initialization
expression is constant (e.g. could be stuck into a `const` if so
desired). This form of thread local allows for a more efficient
implementation of `LocalKey::with` both if the value has a destructor
and if it doesn't. If the value doesn't have a destructor then `with`
should desugar to exactly as-if you use `#[thread_local]` given
sufficient inlining.
The purpose of this new form of thread locals is to precisely be
equivalent to `#[thread_local]` on platforms where possible for values
which fit the bill (those without destructors). This should help close
the gap in performance between `thread_local!`, which is safe, relative
to `#[thread_local]`, which is not easy to use in a portable fashion.
Fix join_paths error display.
On unix, the error from `join_paths` looked like this:
```
path segment contains separator `58`
```
This PR changes it to look like this:
```
path segment contains separator `:`
```
Move `std::sys_common::alloc` to new module `std::sys::common`
6b56603e35/library/std/src/sys_common/mod.rs (L7-L13)
It was my impression that the goal for `std::sys` has changed from extracting it into a separate crate to making std work with features. However the fact remains that there is a lot of interdependence between `sys` and `sys_common`, this is because `sys_common` contains two types of code:
- abstractions over the different platform implementations in `std::sys` (for example [`std::sys_common::mutex`](https://github.com/rust-lang/rust/blob/master/library/std/src/sys_common/mutex.rs))
- code shared between platforms (for example [`std::sys_common::alloc`](https://github.com/rust-lang/rust/blob/master/library/std/src/sys_common/alloc.rs))
This PR attempts to address this by adding a new module `common` to `std::sys` which will contain code shared between platforms, `alloc.rs` in this case but more can be moved over in the future.
Stabilize `bufreader_seek_relative`
This PR marks `BufReader::seek_relative` as stable - the associated issue, #31100, has passed the final comment period without any issues, and from what I understand, the only thing left to stabilize this is to submit a PR marking the method as stable.
Closes#31100.
Turn old edition lint (anonymous-parameters) into warn-by-default on 2015
This makes `anonymous_parameters` <s>and `keyword_idents` </s>warn-by-default on the 2015 edition. I would also like to do this for `absolute_paths_not_starting_with_crate`, but I feel that case is slightly less clear-cut.
Note that this only affects code on the 2015 edition, such code is illegal in future editions anyway.
This was spurred by https://github.com/dtolnay/syn/issues/972: old edition syntax breaks tooling (like syn), and while the tooling should be free to find its balance on how much to support prior editions, it does seem like we should be nudging such code towards the newer edition, and we can do that by turning this Allow lint into a Warn.
In general, I feel like migration lints from an old edition should be made Warn after a year or so, and idiom lints for the new edition should be made Warn after a couple months.
cc `@m-ou-se,` this is for stuff from the 2015-2018 migration but you might be interested.
Update stdarch submodule (to before it switched to const generics)
https://github.com/rust-lang/rust/pull/83278#issuecomment-812389823: This unblocks #82539.
Major changes:
- More AVX-512 intrinsics.
- More ARM & AArch64 NEON intrinsics.
- Updated unstable WASM intrinsics to latest draft standards.
- std_detect is now a separate crate instead of a submodule of std.
I double-checked and the first use of const generics looks like 8d5017861e, which isn't included in this PR.
r? `@Amanieu`
This also includes a cherry-pick of
ec1461905b
and https://github.com/rust-lang/stdarch/pull/1108 to fix a build
failure.
It also adds a re-export of various macros to the crate root of libstd -
previously they would show up automatically because std_detect was defined
in the same crate.
clean up example on read_to_string
This is the same thing, but simpler.
This came out of a comment from a user: https://news.ycombinator.com/item?id=25318117 but rather than hide the signature of main, I think a `use` plus not including the `'static` makes more sense.
Document "standard" conventions for error messages
These are currently documented in the API guidelines:
https://rust-lang.github.io/api-guidelines/interoperability.html#error-types-are-meaningful-and-well-behaved-c-good-err
I think it makes sense to uplift this guideline (in a milder form) into
std docs. Printing and producing errors is something that even
non-expert users do frequently, so it is useful to give at least some
indication of what a typical error message looks like.
