In preparation for upcoming changes to the `Writer` trait (soon to be called
`Write`) this commit renames the current `write` method to `write_all` to match
the semantics of the upcoming `write_all` method. The `write` method will be
repurposed to return a `usize` indicating how much data was written which
differs from the current `write` semantics. In order to head off as much
unintended breakage as possible, the method is being deprecated now in favor of
a new name.
[breaking-change]
In preparation for the I/O rejuvination of the standard library, this commit
renames the current `io` module to `old_io` in order to make room for the new
I/O modules. It is expected that the I/O RFCs will land incrementally over time
instead of all at once, and this provides a fresh clean path for new modules to
enter into as well as guaranteeing that all old infrastructure will remain in
place for some time.
As each `old_io` module is replaced it will be deprecated in-place for new
structures in `std::{io, fs, net}` (as appropriate).
This commit does *not* leave a reexport of `old_io as io` as the deprecation
lint does not currently warn on this form of use. This is quite a large breaking
change for all imports in existing code, but all functionality is retained
precisely as-is and path statements simply need to be renamed from `io` to
`old_io`.
[breaking-change]
There are some explicit Send/Sync implementations for Window's types
that don't exist in Unix. While the end result will be the same, I
believe it's clearer if we keep the explicit implementations consistent
by making the os-specific types Send/Sync where needed and possible.
This commit addresses tcp. Existing differences below:
src/libstd/sys/unix/tcp.rs
unsafe impl Sync for TcpListener {}
unsafe impl Sync for AcceptorInner {}
src/libstd/sys/windows/tcp.rs
unsafe impl Send for Event {}
unsafe impl Sync for Event {}
unsafe impl Send for TcpListener {}
unsafe impl Sync for TcpListener {}
unsafe impl Send for TcpAcceptor {}
unsafe impl Sync for TcpAcceptor {}
unsafe impl Send for AcceptorInner {}
unsafe impl Sync for AcceptorInner {}
There are some explicit Send/Sync implementations for Window's types
that don't exist in Unix. While the end result will be the same, I
believe it's clearer if we keep the explicit implementations consistent
by making the os-specific types Send/Sync where needed and possible.
This commit addresses pipe
src/libstd/sys/unix/pipe.rs
unsafe impl Send for UnixListener {}
unsafe impl Sync for UnixListener {}
src/libstd/sys/windows/pipe.rs
unsafe impl Send for UnixStream {}
unsafe impl Sync for UnixStream {}
unsafe impl Send for UnixListener {}
unsafe impl Sync for UnixListener {}
unsafe impl Send for UnixAcceptor {}
unsafe impl Sync for UnixAcceptor {}
unsafe impl Send for AcceptorState {}
unsafe impl Sync for AcceptorState {}
This commit relaxes the bound on `Result::unwrap` and `Result::unwrap_err` from
the `Display` trait to the `Debug` trait for generating an error message about
the unwrapping operation.
This commit is a breaking change and any breakage should be mitigated by
ensuring that `Debug` is implemented on the relevant type.
[breaking-change]
Per [RFC 517](https://github.com/rust-lang/rfcs/pull/575/), this commit
introduces platform-native strings. The API is essentially as described
in the RFC.
The WTF-8 implementation is adapted from @SimonSapin's
[implementation](https://github.com/SimonSapin/rust-wtf8). To make this
work, some encodign and decoding functionality in `libcore` is now
exported in a "raw" fashion reusable for WTF-8. These exports are *not*
reexported in `std`, nor are they stable.
This commit relaxes the bound on `Result::unwrap` and `Result::unwrap_err` from
the `Display` trait to the `Debug` trait for generating an error message about
the unwrapping operation.
This commit is a breaking change and any breakage should be mitigated by
ensuring that `Debug` is implemented on the relevant type.
[breaking-change]
Previous wording wasn’t clear about its actual behaviour. It could be
interpreted as answering either:
* Can current thread panic?
* Is current thread unwinding because of panic?
r? @steveklabnik
Not sure on what *exactly* should be said here, but I think this is the most important bit. This PR also establishes conventions for describing performance minimally.
I suggest to describe preformance for individual methods we use a `# Performance` heading. Not sure if we should have
```
# Performance: O(1)
details details
```
or
```
# Performance:
O(1)
details details
```
Since I think most methods don't need discussion, the former seems more resonable. But it's kind of weird to have info "in" the heading.
r? @steveklabnik
Initial support for aarch64-linux-android (#18920)
- Add new configuration files
- Modify some options to compile & link succesfully.
(PIE, disable tls on jemalloc, modify some external function linkage, ..)
- To build, refer to https://github.com/rust-lang/rust/wiki/Doc-building-for-android.
(tested with platform=21 and toolchain=aarch64-linux-android-4.9)
This commit is an implementation of [RFC 565][rfc] which is a stabilization of
the `std::fmt` module and the implementations of various formatting traits.
Specifically, the following changes were performed:
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0565-show-string-guidelines.md
* The `Show` trait is now deprecated, it was renamed to `Debug`
* The `String` trait is now deprecated, it was renamed to `Display`
* Many `Debug` and `Display` implementations were audited in accordance with the
RFC and audited implementations now have the `#[stable]` attribute
* Integers and floats no longer print a suffix
* Smart pointers no longer print details that they are a smart pointer
* Paths with `Debug` are now quoted and escape characters
* The `unwrap` methods on `Result` now require `Display` instead of `Debug`
* The `Error` trait no longer has a `detail` method and now requires that
`Display` must be implemented. With the loss of `String`, this has moved into
libcore.
* `impl<E: Error> FromError<E> for Box<Error>` now exists
* `derive(Show)` has been renamed to `derive(Debug)`. This is not currently
warned about due to warnings being emitted on stage1+
While backwards compatibility is attempted to be maintained with a blanket
implementation of `Display` for the old `String` trait (and the same for
`Show`/`Debug`) this is still a breaking change due to primitives no longer
implementing `String` as well as modifications such as `unwrap` and the `Error`
trait. Most code is fairly straightforward to update with a rename or tweaks of
method calls.
[breaking-change]
Closes#21436
After PR #19766 added implicit coersions `*mut T -> *const T`, the explicit casts can be removed.
(The number of such casts turned out to be relatively small).
Two errors in `std::sync` are currently missing implementations of the standard error trait because they contain types which aren't `Send`.
This PR therefore requires #21312.
As discussed with @aturon, this PR removes the `Send` bound from `std::error::Error`, allowing us to implement `Error` for error types containing non-`Send` types. Current examples include `PoisonError` and `TryLockError` from `std::sync` which contain a Guard that we don't want sent between tasks.
[breaking-change]
There are a large number of places that incorrectly refer
to deriving in comments, instead of derives.
If someone could look at src/etc/generate-deriving-span-tests.py,
I'm not sure how those tests were passing before/if they were.
This is a [breaking-change] since `std::dynamic_lib::dl` is now
private.
When `LoadLibraryW()` fails, original code called `errno()` to get error
code. However, there was local allocation of `Vec` before
`LoadLibraryW()`, and it drops before `errno()`, and the drop
(deallocation) changed `errno`! Therefore `dynamic_lib::open()` thought
it always succeeded.
This commit fixes the issue.
This commit also sets Windows error mode during `LoadLibrary()` to
prevent "dll load failed" dialog.
Previous wording wasn’t clear about its actual behaviour. It could be
interpreted as answering either:
* Can current thread panic?
* Is current thread unwinding because of panic?
In accordance with [collections reform part 2][rfc] this macro has been moved to
an external [bitflags crate][crate] which is [available though
crates.io][cratesio]. Inside the standard distribution the macro has been moved
to a crate called `rustc_bitflags` for current users to continue using.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0509-collections-reform-part-2.md
[crate]: https://github.com/rust-lang/bitflags
[cratesio]: http://crates.io/crates/bitflags
The major user of `bitflags!` in terms of a public-facing possibly-stable API
today is the `FilePermissions` structure inside of `std::io`. This user,
however, will likely no longer use `bitflags!` after I/O reform has landed. To
prevent breaking APIs today, this structure remains as-is.
Current users of the `bitflags!` macro should add this to their `Cargo.toml`:
bitflags = "0.1"
and this to their crate root:
#[macro_use] extern crate bitflags;
Due to the removal of a public macro, this is a:
[breaking-change]
I searched for times when we were hiding functions with # in the documentation,
and fixed them to not use it unless neccesary.
I also made random improvements whenever I changed something. For example,
I changed Example to Examples, for consistency.
Fixes#13423
**The implementation is a direct adaptation of libcxx's condition_variable implementation.**
I also added a wait_timeout_with method, which matches the second overload in C++'s condition_variable. The implementation right now is kind of dumb but it works. There is an outstanding issue with it: as is it doesn't support the use case where a user doesn't care about poisoning and wants to continue through poison.
r? @alexcrichton @aturon
**The implementation is a direct adaptation of libcxx's
condition_variable implementation.**
pthread_cond_timedwait uses the non-monotonic system clock. It's
possible to change the clock to a monotonic via pthread_cond_attr, but
this is incompatible with static initialization. To deal with this, we
calculate the timeout using the system clock, and maintain a separate
record of the start and end times with a monotonic clock to be used for
calculation of the return value.
This PR adds rules for negative implementations. It follows pretty much what the [RFC](https://github.com/rust-lang/rfcs/blob/master/text/0019-opt-in-builtin-traits.md) says with 1 main difference:
Instead of positive implementations override negative implementations, this have been implemented in a way that a negative implementation of `Trait` for `T` will overlap with a positive implementation, causing a coherence error.
@nikomatsakis r?
cc #13231
[breaking-change]
Jorge Aparicio
bors
Flavio Percoco
Steven Fackler
Michael Neumann
Manish Goregaokar
Vojtech Kral
Brian Anderson
Felix S. Klock II
Victory
Alex Crichton
Peter Atashian
Aaron Turon
Daniel Griffen
Steve Klabnik
JP Sugarbroad
Barosl LEE
Oliver Schneider
Toby Scrace
Eunji Jeong
Piotr Czarnecki
we
klutzy
Wangshan Lu
Eduard Burtescu
Michael Sproul
Simonas Kazlauskas
Earl St Sauver
Benjamin Peterson