Specialize some `io::Read` and `io::Write` methods for `VecDeque<u8>` and `&[u8]`
This improves implementation of:
- `<&[u8]>::read_to_string`
- `VecDeque<u8>::read_to_end`
- `VecDeque<u8>::read_to_string`
- `VecDeque<u8>::write_vectored`
Added byte position range for `proc_macro::Span`
Currently, the [`Debug`](https://doc.rust-lang.org/beta/proc_macro/struct.Span.html#impl-Debug-for-Span) implementation for [`proc_macro::Span`](https://doc.rust-lang.org/beta/proc_macro/struct.Span.html#) calls the debug function implemented in the trait implementation of `server::Span` for the type `Rustc` in the `rustc-expand` crate.
The current implementation, of the referenced function, looks something like this:
```rust
fn debug(&mut self, span: Self::Span) -> String {
if self.ecx.ecfg.span_debug {
format!("{:?}", span)
} else {
format!("{:?} bytes({}..{})", span.ctxt(), span.lo().0, span.hi().0)
}
}
```
It returns the byte position of the [`Span`](https://doc.rust-lang.org/beta/proc_macro/struct.Span.html#) as an interpolated string.
Because this is currently the only way to get a spans position in the file, I might lead someone, who is interested in this information, to parsing this interpolated string back into a range of bytes, which I think is a very non-rusty way.
The proposed `position()`, method implemented in this PR, gives the ability to directly get this info.
It returns a [`std::ops::Range`](https://doc.rust-lang.org/std/ops/struct.Range.html#) wrapping the lowest and highest byte of the [`Span`](https://doc.rust-lang.org/beta/proc_macro/struct.Span.html#).
I put it behind the `proc_macro_span` feature flag because many of the other functions that have a similar footprint also are annotated with it, I don't actually know if this is right.
It would be great if somebody could take a look at this, thank you very much in advanced.
Negating a non-zero integer currently requires unpacking to a
primitive and re-wrapping. Since negation of non-zero signed
integers always produces a non-zero result, it is safe to
implement `Neg` for `NonZeroI{N}`.
The new `impl` is marked as stable because trait implementations
for two stable types can't be marked unstable.
Support AIX-style archive type
Reading facility of AIX big archive has been supported by `object` since 0.30.0.
Writing facility of AIX big archive has already been supported by `ar_archive_writer`, but we need to bump the version to support the new archive type enum.
Windows: map a few more error codes to ErrorKind
NotFound errors:
* `ERROR_INVALID_DRIVE`: The system cannot find the drive specified
* `ERROR_BAD_NETPATH`: The network path was not found
* `ERROR_BAD_NET_NAME`: The network name cannot be found.
InvalidFilename:
* `ERROR_BAD_PATHNAME`: The specified path is invalid.
Source: [System Error Codes (0-499)](https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-)
NotFound errors:
* `ERROR_INVALID_DRIVE`: The system cannot find the drive specified
* `ERROR_BAD_NETPATH`: The network path was not found
* `ERROR_BAD_NET_NAME`: The network name cannot be found.
InvalidFilename:
* `ERROR_BAD_PATHNAME`: The specified path is invalid.
Use `Display` in top-level example for `PanicInfo`
Addresses https://github.com/rust-lang/rust/issues/110098.
This confused me as well, when I was writing a `no_std` panic handler for the first time, so here's a better top-level example.
`Display` is stable, prints the `.message()` if available, and falls back to `.payload().downcast_ref<&str>()` if the message is not available. So this example should provide strictly more information and also work for formatted panics.
The old example still exists on the `payload` method.
Add links from `core::cmp` derives to their traits
Fixes#109946
Adds intra-doc links from the `core::cmp` derives to their respective traits, and a link to their derive behaviour
`@rustbot` label +A-docs
Add Command environment variable inheritance docs
The interaction between the environment variable methods can be confusing. Specifically `env_clear` and `remove_env` have a side effects not mentioned: they disable inheriting environment variables from the parent process. I wanted to fully document this behavior as well as explain relevant edge cases in each of the `Command` env methods.
This is further confused by the return of `get_envs` which will return key/None if `remove_env` has been used, but an empty iterator if `env_clear` has been called. Or a non-empty iterator if `env_clear` was called and later explicit mappings are added. Currently there is no way (that I'm able to find) of observing whether or not the internal `env_clear=true` been toggled on the `Command` struct via its public API.
Ultimately environment variable mappings can be in one of several states:
- Explicitly set value (via `envs` / `env`) will take precedence over parent mapping
- Not explicitly set, will inherit mapping from parent
- Explicitly removed via `remove_env`, this single mapping will not inherit from parent
- Implicitly removed via `env_clear`, no mappings will inherit from parent
I tried to represent this in the relevant sections of the docs.
This is my second-ever doc PR (whoop!). I'm happy to take specific or general doc feedback. Also happy to explain the logic behind any changes or additions I made.
Add `tidy-alphabetical` to features in `alloc` & `std`
So that people have to keep them sorted in future, rather than just sticking them on the end where they conflict more often.
Follow-up to #110269
cc `@jyn514`
Add `tidy-alphabetical` to features in `core`
So that people have to keep them sorted in future, rather than just sticking them on the end where they conflict more often.
