Correct code points to match their textual description
Probably due to a copy-paste error, in the sentence
> For example, despite looking similar, the 'é' character is one Unicode code point while 'é' is two Unicode code points:
the two `é`'s were actually the same character in the text (i.e. the same Unicode character U+00E9).
The code listing below instead had two different Unicode characters for the two `é`s, as it was supposed to.
The example shown wasn't clear at first so I started inspecting the text and found this out.
I simply copied the character from the code listing to the description surrounding the code.
It's a minor thing but I thought it would make things clearer for others, especially since the example is about how Rust handles `char`s.
This distinction is fairly abstract, but in practice, the main advantage
here is that LLVM's triple code considers WASI to be an OS, so this
makes rustc agree with that.
Fix potential integer overflow in SGX memory range calculation.
Thanks to Eduard Marin and David Oswald at the University of Burmingham, and Jo Van Bulck at KU Leuven for discovering this issue.
Make `std::fs::copy` attempt to create copy-on-write clones of files on MacOS
The behaviour of MacOS now matches Linux which uses `copy_file_range` to perform CoW file copies where available and supported by the underlying filesystem.
use SecRandomCopyBytes on macOS in Miri
This is a hack to fix https://github.com/rust-lang/miri/issues/686: on macOS, rustc will open `/dev/urandom` to initialize a `HashMap`. That's quite hard to emulate properly in Miri without a full-blown implementation of file descriptors. However, Miri needs an implementation of `SecRandomCopyBytes` anyway to support [getrandom](https://crates.io/crates/getrandom), so using it here should work just as well.
This will only have an effect when libstd is compiled specifically for Miri, but that will generally be the case when people use `cargo miri`.
This is clearly a hack, so I am opening this to start a discussion about whether we are okay with such a hack or not.
Cc @oli-obk
Extend the std::process::Child docs with warning about possible zombies.
The previous version mentioned that when dropping the Child, the
process is not killed. However, the wording gave the impression that
such behaviour is fine to do (leaving the reader believe low-level
details like reaping zombies of the dead processes is taken over by std
somehow; or simply leaving the reader unaware about the problem).
Debug-print error when using rtunwrap
When I added this macro a while back I didn't have a way to make it print the failure for all types that you might want to unwrap. Now, I came up with a solution.
Stabilized vectored IO
This renames `std::io::IoVec` to `std::io::IoSlice` and
`std::io::IoVecMut` to `std::io::IoSliceMut`, and stabilizes
`std::io::IoSlice`, `std::io::IoSliceMut`,
`std::io::Read::read_vectored`, and `std::io::Write::write_vectored`.
Closes#58452
r? @alexcrichton
Document `Item` type in `std::env::SplitPaths` iterator.
Previously there wasn't any documentation to show what the type of
`Item` was inside `std::env::SplitPaths`. Now, in the same format as
other examples of docs in `std` for `Iterator#Item`, we mention the
type.
This fixes#59543.
r? @steveklabnik
This renames `std::io::IoVec` to `std::io::IoSlice` and
`std::io::IoVecMut` to `std::io::IoSliceMut`, and stabilizes
`std::io::IoSlice`, `std::io::IoSliceMut`,
`std::io::Read::read_vectored`, and `std::io::Write::write_vectored`.
Closes#58452
Reexport IntErrorKind in std
Currently `IntErrorKind` can only be found in `core`. @Centril confirmed on Discord that this is unintentional (should I r? him in this situation?).
Should there be a test for this? As far as this *specific* situation goes, I don't think so, I'll risk it and say that there's no way this regresses. However, it might be a good idea to have some tool detect public items in `core` that are not reexported in `std`. Does this belong in tidy, or should that be a separate tool? Is there some rustc-specific *linter*? Unless that's entirely a dumb idea, this should probably get an issue.
Note: My local build hasn't finished yet, but it's well past the point where I would expect problems.
Replace HashMap implementation with SwissTable (as an external crate)
This is the same as #56241 except that it imports `hashbrown` as an external crate instead of copying the implementation into libstd.
This includes a few API changes (all unstable):
- `try_reserve` is added to `HashSet`.
- Some trait bounds have been changed in the `raw_entry` API.
- `search_bucket` has been removed from the `raw_entry` API (doesn't work with SwissTable).
Disallow double trailing newlines in tidy
This wasn't done previously in https://github.com/rust-lang/rust/pull/47064#issuecomment-354533010 as it affected too many files, but I think it's best to fix it now so that the number of files with double trailing newlines doesn't keep increasing.
r? kennytm
Fix sync_all on macos/ios
`sync_all` should flush all metadata in macos/ios, so it should call `fcntl` with the `F_FULLFSYNC` flag as `sync_data` does.
Note that without this `sync_data` performs more flushes than `sync_all` on macos/ios.
Remove collection-specific `with_capacity` documentation from `std::collections`
Fixes#59931
The style of `std::collections` module doc is very much a beginner friendly guide, and documenting niche, collection-specific behaviour feels out of place, if not brittle.
The note about `VecDeque` is outdated (see issue), and while `Vec` probably won't change its guarantees any time soon, the users who are interested in its allocation properties will find that in its own documentation.
Previously there wasn't any documentation to show what the type of
`Item` was inside `std::env::SplitPaths`. Now, in the same format as
other examples of docs in `srd` for `Iterator#Item`, we mention the
type.
This fixes#59543.
