Implement 1581 (FusedIterator)
* [ ] Implement on patterns. See https://github.com/rust-lang/rust/issues/27721#issuecomment-239638642.
* [ ] Handle OS Iterators. A bunch of iterators (`Args`, `Env`, etc.) in libstd wrap platform specific iterators. The current ones all appear to be well-behaved but can we assume that future ones will be?
* [ ] Does someone want to audit this? On first glance, all of the iterators on which I implemented `FusedIterator` appear to be well-behaved but there are a *lot* of them so a second pair of eyes would be nice.
* I haven't touched rustc internal iterators (or the internal rand) because rustc doesn't actually call `fuse()`.
* `FusedIterator` can't be implemented on `std::io::{Bytes, Chars}`.
Closes: #35602 (Tracking Issue)
Implements: rust-lang/rfcs#1581
Long ago we discovered that threads which outlive main and then exit while the
rest of the program is exiting causes Windows to hang (#20704). That's what was
happening in this test so let's just not run this test any more.
Improve arc doc, fixing #32905
As issue #32905 detailed, I moved part of the module doc to the struct doc, and fixed some small places in the `alloc::arc`.
The original description suggests that the original `Rc<T>` itself is downgraded, which doesn't seem to be what the code does. At the same time, `Rc` is one of those types that can do weird things with only a shared reference, so I thought it would be good to be clear.
Support 16-bit pointers as well as i/usize
I'm opening this pull request to get some feedback from the community.
Although Rust doesn't support any platforms with a native 16-bit pointer at the moment, the [AVR-Rust][ar] fork is working towards that goal. Keeping this forked logic up-to-date with the changes in master has been onerous so I'd like to merge these changes so that they get carried along when refactoring happens. I do not believe this should increase the maintenance burden.
This is based on the original work of Dylan McKay (@dylanmckay).
[ar]: https://github.com/avr-rust/rust
rustbuild: Add support for crate tests + doctests
This commit adds support to rustbuild to run crate unit tests (those defined by
`#[test]`) as well as documentation tests. All tests are powered by `cargo test`
under the hood.
Each step requires the `libtest` library is built for that corresponding stage.
Ideally the `test` crate would be a dev-dependency, but for now it's just easier
to ensure that we sequence everything in the right order.
Currently no filtering is implemented, so there's not actually a method of
testing *only* libstd or *only* libcore, but rather entire swaths of crates are
tested all at once.
A few points of note here are:
* The `coretest` and `collectionstest` crates are just listed as `[[test]]`
entires for `cargo test` to naturally pick up. This mean that `cargo test -p
core` actually runs all the tests for libcore.
* Libraries that aren't tested all mention `test = false` in their `Cargo.toml`
* Crates aren't currently allowed to have dev-dependencies due to
rust-lang/cargo#860, but we can likely alleviate this restriction once
workspaces are implemented.
cc #31590
This commit adds support to rustbuild to run crate unit tests (those defined by
`#[test]`) as well as documentation tests. All tests are powered by `cargo test`
under the hood.
Each step requires the `libtest` library is built for that corresponding stage.
Ideally the `test` crate would be a dev-dependency, but for now it's just easier
to ensure that we sequence everything in the right order.
Currently no filtering is implemented, so there's not actually a method of
testing *only* libstd or *only* libcore, but rather entire swaths of crates are
tested all at once.
A few points of note here are:
* The `coretest` and `collectionstest` crates are just listed as `[[test]]`
entires for `cargo test` to naturally pick up. This mean that `cargo test -p
core` actually runs all the tests for libcore.
* Libraries that aren't tested all mention `test = false` in their `Cargo.toml`
* Crates aren't currently allowed to have dev-dependencies due to
rust-lang/cargo#860, but we can likely alleviate this restriction once
workspaces are implemented.
cc #31590
Right now everything in TARGET_CRATES is built by default for all non-fulldeps
tests and is distributed by default for all target standard library packages.
Currenly this includes a number of unstable crates which are rarely used such as
`graphviz` and `rbml`>
This commit trims down the set of `TARGET_CRATES`, moves a number of tests to
`*-fulldeps` as a result, and trims down the dependencies of libtest so we can
distribute fewer crates in the `rust-std` packages.
This commit is the result of the FCPs ending for the 1.8 release cycle for both
the libs and the lang suteams. The full list of changes are:
Stabilized
* `braced_empty_structs`
* `augmented_assignments`
* `str::encode_utf16` - renamed from `utf16_units`
* `str::EncodeUtf16` - renamed from `Utf16Units`
* `Ref::map`
* `RefMut::map`
* `ptr::drop_in_place`
* `time::Instant`
* `time::SystemTime`
* `{Instant,SystemTime}::now`
* `{Instant,SystemTime}::duration_since` - renamed from `duration_from_earlier`
* `{Instant,SystemTime}::elapsed`
* Various `Add`/`Sub` impls for `Time` and `SystemTime`
* `SystemTimeError`
* `SystemTimeError::duration`
* Various impls for `SystemTimeError`
* `UNIX_EPOCH`
* `ops::{Add,Sub,Mul,Div,Rem,BitAnd,BitOr,BitXor,Shl,Shr}Assign`
Deprecated
* Scoped TLS (the `scoped_thread_local!` macro)
* `Ref::filter_map`
* `RefMut::filter_map`
* `RwLockReadGuard::map`
* `RwLockWriteGuard::map`
* `Condvar::wait_timeout_with`
Closes#27714Closes#27715Closes#27746Closes#27748Closes#27908Closes#29866
This allows printing pointers to unsized types with the {:p} formatting
directive. The following impls are extended to unsized types:
- impl<'a, T: ?Sized> Pointer for &'a T
- impl<'a, T: ?Sized> Pointer for &'a mut T
- impl<T: ?Sized> Pointer for *const T
- impl<T: ?Sized> Pointer for *mut T
- impl<T: ?Sized> fmt::Pointer for Box<T>
- impl<T: ?Sized> fmt::Pointer for Rc<T>
- impl<T: ?Sized> fmt::Pointer for Arc<T>
The documentation for the `make_mut` function on `Arc<T>` contains a somewhat impenetrable double-negative that I was only able to fully grasp by looking at the implementation. Here's a quick rewrite that reads a lot better.
The sentence "doesn't have one strong reference and no weak references." is a
hard to understand, and it can be much more easily explained. In particular, such a double-negative
could give English as a Second Language users even more trouble than native speakers.
r? @steveklabnik
This allows printing pointers to unsized types with the {:p} formatting
directive. The following impls are extended to unsized types:
- impl<'a, T: ?Sized> Pointer for &'a T
- impl<'a, T: ?Sized> Pointer for &'a mut T
- impl<T: ?Sized> Pointer for *const T
- impl<T: ?Sized> Pointer for *mut T
- impl<T: ?Sized> fmt::Pointer for Box<T>
- impl<T: ?Sized> fmt::Pointer for Rc<T>
- impl<T: ?Sized> fmt::Pointer for Arc<T>
Changed the description of the `make_mut` copy-on-write behaviour in arc.rs
The sentence "doesn't have one strong reference and no weak references." is a
hard to understand double negative, which can be much more easily explained.
