Linking __pthread_get_minstack, even weakly, was causing Debian’s
dpkg-shlibdeps to detect an unnecessarily strict versioned dependency
on libc6.
Closes#23628.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
This commit removes the `IndexMut` impls on `HashMap` and `BTreeMap`, in
order to future-proof the API against the eventual inclusion of an
`IndexSet` trait.
Ideally, we would eventually be able to support:
```rust
map[owned_key] = val;
map[borrowed_key].mutating_method(arguments);
&mut map[borrowed_key];
```
but to keep the design space as unconstrained as possible, we do not
currently want to support `IndexMut`, in case some other strategy will
eventually be needed.
Code currently using mutating index notation can use `get_mut` instead.
[breaking-change]
Closes#23448
r? @Gankro
There have been some recent panics on the bots and this commit is an attempt to
appease them. Previously it was considered invalid to run `rt::at_exit` after
the handlers had already started running. Due to the multithreaded nature of
applications, however, it is not always possible to guarantee this. For example
[this program][ex] will show off the abort.
[ex]: https://gist.github.com/alexcrichton/56300b87af6fa554e52d
The semantics of the `rt::at_exit` function have been modified as such:
* It is now legal to call `rt::at_exit` at any time. The return value now
indicates whether the closure was successfully registered or not. Callers must
now decide what to do with this information.
* The `rt::at_exit` handlers will now be run for a fixed number of iterations.
Common cases (such as the example shown) may end up registering a new handler
while others are running perhaps once or twice, so this common condition is
covered by re-running the handlers a fixed number of times, after which new
registrations are forbidden.
Some usage of `rt::at_exit` was updated to handle these new semantics, but
deprecated or unstable libraries calling `rt::at_exit` were not updated.
The method with which backwards compatibility was retained ended up leading to
documentation that rustdoc didn't handle well and largely ended up confusing.
This commit removes the reexports of `old_io` traits as well as `old_path` types
and traits from the prelude. This functionality is now all deprecated and needs
to be removed to make way for other functionality like `Seek` in the `std::io`
module (currently reexported as `NewSeek` in the io prelude).
Closes#23377Closes#23378
This commit removes the reexports of `old_io` traits as well as `old_path` types
and traits from the prelude. This functionality is now all deprecated and needs
to be removed to make way for other functionality like `Seek` in the `std::io`
module (currently reexported as `NewSeek` in the io prelude).
Closes#23377Closes#23378
This reverts commit aec67c2.
Closes#20012
This is temporarily rebased on #23245 as it would otherwise conflict, the last commit is the only one relevant to this PR though.
This commit removes the `IndexMut` impls on `HashMap` and `BTreeMap`, in
order to future-proof the API against the eventual inclusion of an
`IndexSet` trait.
Ideally, we would eventually be able to support:
```rust
map[owned_key] = val;
map[borrowed_key].mutating_method(arguments);
&mut map[borrowed_key];
```
but to keep the design space as unconstrained as possible, we do not
currently want to support `IndexMut`, in case some other strategy will
eventually be needed.
Code currently using mutating index notation can use `get_mut` instead.
[breaking-change]
Closes#23448
As @alexcrichton says, this was really a libgreen thing, and isn't
relevant now.
As this removes a technically-public function, this is a
[breaking-change]
The IP and socket address types all had `FromStr` implemented but the
implementations were not marked stable, nor was the error type returned ready to
be properly stabilized.
This commit marks the implementations of `FromStr` as stable and also renamed
the `ParseError` structure to `AddrParseError`. The error is now also an opaque
structure that cannot be constructed outside the standard library.
cc #22949
[breaking-change]
As @alexcrichton says, this was really a libgreen thing, and isn't
relevant now.
As this removes a technically-public function, this is a
[breaking-change]
Conflicts:
src/libtest/lib.rs
This commit stabilizes the `ErrorKind` enumeration which is consumed by and
generated by the `io::Error` type. The purpose of this type is to serve as a
cross-platform namespace to categorize errors into. Two specific issues are
addressed as part of this stablization:
* The naming of each variant was scrutinized and some were tweaked. An example
is how `FileNotFound` was renamed to simply `NotFound`. These names should not
show either a Unix or Windows bias and the set of names is intended to grow
over time. For now the names will likely largely consist of those errors
generated by the I/O APIs in the standard library.
* The mapping of OS error codes onto kinds has been altered. Coalescing no
longer occurs (multiple error codes become one kind). It is intended that each
OS error code, if bound, corresponds to only one `ErrorKind`. The current set
of error kinds was expanded slightly to include some networking errors.
This commit also adds a `raw_os_error` function which returns an `Option<i32>`
to extract the underlying raw error code from the `Error`.
Closes#16666
[breaking-change]
This commit stabilizes the `ErrorKind` enumeration which is consumed by and
generated by the `io::Error` type. The purpose of this type is to serve as a
cross-platform namespace to categorize errors into. Two specific issues are
addressed as part of this stablization:
* The naming of each variant was scrutinized and some were tweaked. An example
is how `FileNotFound` was renamed to simply `NotFound`. These names should not
show either a Unix or Windows bias and the set of names is intended to grow
over time. For now the names will likely largely consist of those errors
generated by the I/O APIs in the standard library.
* The mapping of OS error codes onto kinds has been altered. Coalescing no
longer occurs (multiple error codes become one kind). It is intended that each
OS error code, if bound, corresponds to only one `ErrorKind`. The current set
of error kinds was expanded slightly to include some networking errors.
This commit also adds a `raw_os_error` function which returns an `Option<i32>`
to extract the underlying raw error code from the `Error`.
This commit marks as `#[stable]` the `Entry` types for the maps provided
by `std`. The main reason these had been left unstable previously was
uncertainty about an eventual trait design, but several plausible
designs have been proposed that all work fine with the current type definitions.
unbreak openbsd/bitrig build
- remove `pub` from `struct` (error: visibility has no effect inside functions)
- move `pthread_main_np` into function
r? @alexcrichton
The IP and socket address types all had `FromStr` implemented but the
implementations were not marked stable, nor was the error type returned ready to
be properly stabilized.
This commit marks the implementations of `FromStr` as stable and also renamed
the `ParseError` structure to `AddrParseError`. The error is now also an opaque
structure that cannot be constructed outside the standard library.
cc #22949
[breaking-change]
Nothing inside of the read/write interface itself can panic, so any
poison must have been the result of user code which the lock isn't
protecting.
This seems safe to me, but if we don't want to go this route we should update the docs to indicate that these methods can panic.
r? @alexcrichton
Very minor fix: in `std::net::Ipv6Addr::new`, the documentation had an incomplete representation of the resulting address, missing the last two groups.
This commit clarifies some of the unstable features in the `str` module by
moving them out of the blanket `core` and `collections` features.
The following methods were moved to the `str_char` feature which generally
encompasses decoding specific characters from a `str` and dealing with the
result. It is unclear if any of these methods need to be stabilized for 1.0 and
the most conservative route for now is to continue providing them but to leave
them as unstable under a more specific name.
* `is_char_boundary`
* `char_at`
* `char_range_at`
* `char_at_reverse`
* `char_range_at_reverse`
* `slice_shift_char`
The following methods were moved into the generic `unicode` feature as they are
specifically enabled by the `unicode` crate itself.
* `nfd_chars`
* `nfkd_chars`
* `nfc_chars`
* `graphemes`
* `grapheme_indices`
* `width`
This patch changes the type of byte string literals from `&[u8]` to `&[u8; N]`.
It also implements some necessary traits (`IntoBytes`, `Seek`, `Read`, `BufRead`) for fixed-size arrays (also related to #21725) and adds test for #17233, which seems to be resolved.
Fixes#18465
[breaking-change]
This commit clarifies some of the unstable features in the `str` module by
moving them out of the blanket `core` and `collections` features.
The following methods were moved to the `str_char` feature which generally
encompasses decoding specific characters from a `str` and dealing with the
result. It is unclear if any of these methods need to be stabilized for 1.0 and
the most conservative route for now is to continue providing them but to leave
them as unstable under a more specific name.
* `is_char_boundary`
* `char_at`
* `char_range_at`
* `char_at_reverse`
* `char_range_at_reverse`
* `slice_shift_char`
The following methods were moved into the generic `unicode` feature as they are
specifically enabled by the `unicode` crate itself.
* `nfd_chars`
* `nfkd_chars`
* `nfc_chars`
* `graphemes`
* `grapheme_indices`
* `width`
This function is the current replacement for `std::old_io::timer` which will
soon be deprecated. This function is unstable and has its own feature gate as it
does not yet have an RFC nor has it existed for very long.
This function is the current replacement for `std::old_io::timer` which will
soon be deprecated. This function is unstable and has its own feature gate as it
does not yet have an RFC nor has it existed for very long.
Very minor fix: in `std::net::Ipv6Addr::new`, the documentation had an incomplete representation of the resulting address, missing the last two groups.
The [associated RFC][rfc] for possibly splitting out `flush` has been closed and
as a result there are no more blockers for stabilizing this method, so this
commit marks the method as such.
[rfc]: https://github.com/rust-lang/rfcs/pull/950
- Allow inherent implementations on `char`, `str`, `[T]`, `*const T`, `*mut T` and all the numeric primitives.
- copy `unicode::char::CharExt` methods into `impl char`
- remove `unicode::char::CharExt`, its re-export `std::char::CharExt` and `CharExt` from the prelude
- copy `collections::str::StrExt` methods into `impl str`
- remove `collections::str::StrExt` its re-export `std::str::StrExt`, and `StrExt` from the prelude
- copy `collections::slice::SliceExt` methods into `impl<T> [T]`
- remove `collections::slice::SliceExt` its re-export `std::slice::SliceExt`, and `SliceExt` from the prelude
- copy `core::ptr::PtrExt` methods into `impl<T> *const T`
- remove `core::ptr::PtrExt` its re-export `std::ptr::PtrExt`, and `PtrExt` from the prelude
- copy `core::ptr::PtrExt` and `core::ptr::MutPtrExt` methods into `impl<T> *mut T`
- remove `core::ptr::MutPtrExt` its re-export `std::ptr::MutPtrExt`, and `MutPtrExt` from the prelude
- copy `core::num::Int` and `core::num::SignedInt` methods into `impl i{8,16,32,64,size}`
- copy `core::num::Int` and `core::num::UnsignedInt` methods into `impl u{8,16,32,64,size}`
- remove `core::num::UnsignedInt` and its re-export `std::num::UnsignedInt`
- move `collections` tests into its own crate: `collectionstest`
- copy `core::num::Float` methods into `impl f{32,64}`
Because this PR removes several traits, this is a [breaking-change], however functionality remains unchanged and breakage due to unresolved imports should be minimal. If you encounter an error due to an unresolved import, simply remove the import:
``` diff
fn main() {
- use std::num::UnsignedInt; //~ error: unresolved import `std::num::UnsignedInt`.
-
println!("{}", 8_usize.is_power_of_two());
}
```
---
cc #16862
[preview docs](http://japaric.github.io/inherent/std/index.html)
[unicode::char](http://japaric.github.io/inherent/unicode/primitive.char.html)
[collections::str](http://japaric.github.io/inherent/collections/primitive.str.html)
[std::f32](http://japaric.github.io/inherent/std/primitive.f32.html)
This commit performs a stabilization pass over the std::net module,
incorporating the changes from RFC 923. Specifically, the following actions were
taken:
Stable functionality:
* `net` (the name)
* `Shutdown`
* `Shutdown::{Read, Write, Both}`
* `lookup_host`
* `LookupHost`
* `SocketAddr`
* `SocketAddr::{V4, V6}`
* `SocketAddr::port`
* `SocketAddrV4`
* `SocketAddrV4::{new, ip, port}`
* `SocketAddrV6`
* `SocketAddrV4::{new, ip, port, flowinfo, scope_id}`
* Common trait impls for socket addr structures
* `ToSocketAddrs`
* `ToSocketAddrs::Iter`
* `ToSocketAddrs::to_socket_addrs`
* `ToSocketAddrs for {SocketAddr*, (Ipv*Addr, u16), str, (str, u16)}`
* `Ipv4Addr`
* `Ipv4Addr::{new, octets, to_ipv6_compatible, to_ipv6_mapped}`
* `Ipv6Addr`
* `Ipv6Addr::{new, segments, to_ipv4}`
* `TcpStream`
* `TcpStream::connect`
* `TcpStream::{peer_addr, local_addr, shutdown, try_clone}`
* `{Read,Write} for {TcpStream, &TcpStream}`
* `TcpListener`
* `TcpListener::bind`
* `TcpListener::{local_addr, try_clone, accept, incoming}`
* `Incoming`
* `UdpSocket`
* `UdpSocket::bind`
* `UdpSocket::{recv_from, send_to, local_addr, try_clone}`
Unstable functionality:
* Extra methods on `Ipv{4,6}Addr` for various methods of inspecting the address
and determining qualities of it.
* Extra methods on `TcpStream` to configure various protocol options.
* Extra methods on `UdpSocket` to configure various protocol options.
Deprecated functionality:
* The `socket_addr` method has been renamed to `local_addr`
This commit is a breaking change due to the restructuring of the `SocketAddr`
type as well as the renaming of the `socket_addr` method. Migration should be
fairly straightforward, however, after accounting for the new level of
abstraction in `SocketAddr` (protocol distinction at the socket address level,
not the IP address).
[breaking-change]
The [associated RFC][rfc] for possibly splitting out `flush` has been closed and
as a result there are no more blockers for stabilizing this method, so this
commit marks the method as such.
[rfc]: https://github.com/rust-lang/rfcs/pull/950
This commit deprecates the `count`, `range` and `range_step` functions
in `iter`, in favor of range notation. To recover all existing
functionality, a new `step_by` adapter is provided directly on `ops::Range`
and `ops::RangeFrom`.
[breaking-change]
r? @alexcrichton
r? @alexcrichton or @aturon
This still needs to somehow figure out how to avoid unstable warnings arising from the use of unstable functions. I tried to use `#[allow_internal_unstable]` but it still spits out warnings as far as I can see. @huonw (I think you implemented it) does `#[allow_internal_unstable]` not work for some reason or am I using it incorrectly?
This commit starts to organize the `std::os::$platform` modules and in the
process stabilizes some of the functionality contained within. The organization
of these modules will reflect the organization of the standard library itself
with extension traits for primitives in the same corresponding module.
The OS-specific modules will grow more functionality over time including
concrete types that are not extending functionality of other structures, and
these will either go into the closest module in `std::os::$platform` or they
will grow a new module in the hierarchy.
The following items are now stable:
* `os::{unix, windows}`
* `unix::ffi`
* `unix::ffi::OsStrExt`
* `unix::ffi::OsStrExt::{from_bytes, as_bytes, to_cstring}`
* `unix::ffi::OsString`
* `unix::ffi::OsStringExt::{from_vec, into_vec}`
* `unix::process`
* `unix::process::CommandExt`
* `unix::process::CommandExt::{uid, gid}`
* `unix::process::ExitStatusExt`
* `unix::process::ExitStatusExt::signal`
* `unix::prelude`
* `windows::ffi`
* `windows::ffi::OsStringExt`
* `windows::ffi::OsStringExt::from_wide`
* `windows::ffi::OsStrExt`
* `windows::ffi::OsStrExt::encode_wide`
* `windows::prelude`
The following items remain unstable:
* `unix::io`
* `unix::io::{Fd, AsRawFd}`
* `unix::fs::{PermissionsExt, OpenOptionsExt}`
* `windows::io`
* `windows::io::{Handle, AsRawHandle}`
* `windows::io::{Socket, AsRawSocket}`
* `windows::fs`
* `windows::fs::OpenOptionsExt`
Due to the reorgnization of the platform extension modules, this commit is a
breaking change. Most imports can be fixed by adding the relevant libstd module
in the `use` path (such as `ffi` or `fs`).
[breaking-change]
This commit starts to organize the `std::os::$platform` modules and in the
process stabilizes some of the functionality contained within. The organization
of these modules will reflect the organization of the standard library itself
with extension traits for primitives in the same corresponding module.
The OS-specific modules will grow more functionality over time including
concrete types that are not extending functionality of other structures, and
these will either go into the closest module in `std::os::$platform` or they
will grow a new module in the hierarchy.
The following items are now stable:
* `os::{unix, windows}`
* `unix::ffi`
* `unix::ffi::OsStrExt`
* `unix::ffi::OsStrExt::{from_bytes, as_bytes, to_cstring}`
* `unix::ffi::OsString`
* `unix::ffi::OsStringExt::{from_vec, into_vec}`
* `unix::process`
* `unix::process::CommandExt`
* `unix::process::CommandExt::{uid, gid}`
* `unix::process::ExitStatusExt`
* `unix::process::ExitStatusExt::signal`
* `unix::prelude`
* `windows::ffi`
* `windows::ffi::OsStringExt`
* `windows::ffi::OsStringExt::from_wide`
* `windows::ffi::OsStrExt`
* `windows::ffi::OsStrExt::encode_wide`
* `windows::prelude`
The following items remain unstable:
* `unix::io`
* `unix::io::{Fd, AsRawFd}`
* `unix::fs::{PermissionsExt, OpenOptionsExt}`
* `windows::io`
* `windows::io::{Handle, AsRawHandle}`
* `windows::io::{Socket, AsRawSocket}`
* `windows::fs`
* `windows::fs::OpenOptionsExt`
Due to the reorgnization of the platform extension modules, this commit is a
breaking change. Most imports can be fixed by adding the relevant libstd module
in the `use` path (such as `ffi` or `fs`).
[breaking-change]
`std::io` does not currently expose the `stdin_raw`, `stdout_raw`, or
`stderr_raw` functions. According to the current plans for stdio (see
rust-lang/rfcs#517), raw access will likely be provided using the
platform-specific `std::os::{unix,windows}` modules. At the moment we
don't expose any way to do this. As such, delete all mention of the
`*_raw` functions from the `stdin`/`stdout`/`stderr` function
documentation.
While we're at it, remove a few `pub`s from items that aren't exposed.
This is done just to lessen the confusion experienced by anyone who
looks at the source in an attempt to find the `*_raw` functions.
Recent changes in path semantics meant that if none of the components in a
relative path existed as a part of a call to `create_dir_all` then the call
would fail as `create_dir("")` would be attempted and would fail with an OS
error.
It is a frequent pattern among I/O functions to take `P: AsPath + ?Sized` or
`AsOsStr` instead of `AsPath`. Most of these functions do not need to take
ownership of their argument, but for libraries in general it's much more
ergonomic to not deal with `?Sized` at all and simply require an argument `P`
instead of `&P`.
This change is aimed at removing unsightly `?Sized` bounds while retaining the
same level of usability as before. All affected functions now take ownership of
their arguments instead of taking them by reference, but due to the forwarding
implementations of `AsOsStr` and `AsPath` all code should continue to work as it
did before.
This is strictly speaking a breaking change due to the signatures of these
functions changing, but normal idiomatic usage of these APIs should not break in
practice.
[breaking-change]
std::io does not currently expose the stdin_raw, stdout_raw, or
stderr_raw functions. According to the current plans for stdio (see RFC
#517), raw access will likely be provided using the platform-specific
std::os::{unix,windows} modules. At the moment we don't expose any way
to do this. As such, delete all mention of the _raw functions from the
stdin/stdout/stderr function documentation.
While we're at it, remove a few `pub`s from items that aren't exposed.
This is done just to lessen the confusion experienced by anyone who
looks at the source in an attempt to find the _raw functions.
at least that's what the docs say: http://doc.rust-lang.org/std/slice/fn.from_raw_parts.html
A few situations got prettier. In some situations the mutability of the resulting and source pointers differed (and was cast away by transmute), the mutability matches now.
This commit performs a stabilization pass over the std::net module,
incorporating the changes from RFC 923. Specifically, the following actions were
taken:
Stable functionality:
* `net` (the name)
* `Shutdown`
* `Shutdown::{Read, Write, Both}`
* `lookup_host`
* `LookupHost`
* `SocketAddr`
* `SocketAddr::{V4, V6}`
* `SocketAddr::port`
* `SocketAddrV4`
* `SocketAddrV4::{new, ip, port}`
* `SocketAddrV6`
* `SocketAddrV4::{new, ip, port, flowinfo, scope_id}`
* Common trait impls for socket addr structures
* `ToSocketAddrs`
* `ToSocketAddrs::Iter`
* `ToSocketAddrs::to_socket_addrs`
* `ToSocketAddrs for {SocketAddr*, (Ipv*Addr, u16), str, (str, u16)}`
* `Ipv4Addr`
* `Ipv4Addr::{new, octets, to_ipv6_compatible, to_ipv6_mapped}`
* `Ipv6Addr`
* `Ipv6Addr::{new, segments, to_ipv4}`
* `TcpStream`
* `TcpStream::connect`
* `TcpStream::{peer_addr, local_addr, shutdown, try_clone}`
* `{Read,Write} for {TcpStream, &TcpStream}`
* `TcpListener`
* `TcpListener::bind`
* `TcpListener::{local_addr, try_clone, accept, incoming}`
* `Incoming`
* `UdpSocket`
* `UdpSocket::bind`
* `UdpSocket::{recv_from, send_to, local_addr, try_clone}`
Unstable functionality:
* Extra methods on `Ipv{4,6}Addr` for various methods of inspecting the address
and determining qualities of it.
* Extra methods on `TcpStream` to configure various protocol options.
* Extra methods on `UdpSocket` to configure various protocol options.
Deprecated functionality:
* The `socket_addr` method has been renamed to `local_addr`
This commit is a breaking change due to the restructuring of the `SocketAddr`
type as well as the renaming of the `socket_addr` method. Migration should be
fairly straightforward, however, after accounting for the new level of
abstraction in `SocketAddr` (protocol distinction at the socket address level,
not the IP address).
[breaking-change]
This commit deprecates the `count`, `range` and `range_step` functions
in `iter`, in favor of range notation. To recover all existing
functionality, a new `step_by` adapter is provided directly on `ops::Range`
and `ops::RangeFrom`.
[breaking-change]
The new `std::io` module has had some time to bake now, and this commit
stabilizes its functionality. There are still portions of the module which
remain unstable, and below contains a summart of the actions taken.
This commit also deprecates the entire contents of the `old_io` module in a
blanket fashion. All APIs should now have a reasonable replacement in the
new I/O modules.
Stable APIs:
* `std::io` (the name)
* `std::io::prelude` (the name)
* `Read`
* `Read::read`
* `Read::{read_to_end, read_to_string}` after being modified to return a `usize`
for the number of bytes read.
* `Write`
* `Write::write`
* `Write::{write_all, write_fmt}`
* `BufRead`
* `BufRead::{fill_buf, consume}`
* `BufRead::{read_line, read_until}` after being modified to return a `usize`
for the number of bytes read.
* `BufReader`
* `BufReader::{new, with_capacity}`
* `BufReader::{get_ref, get_mut, into_inner}`
* `{Read,BufRead} for BufReader`
* `BufWriter`
* `BufWriter::{new, with_capacity}`
* `BufWriter::{get_ref, get_mut, into_inner}`
* `Write for BufWriter`
* `IntoInnerError`
* `IntoInnerError::{error, into_inner}`
* `{Error,Display} for IntoInnerError`
* `LineWriter`
* `LineWriter::{new, with_capacity}` - `with_capacity` was added
* `LineWriter::{get_ref, get_mut, into_inner}` - `get_mut` was added)
* `Write for LineWriter`
* `BufStream`
* `BufStream::{new, with_capacities}`
* `BufStream::{get_ref, get_mut, into_inner}`
* `{BufRead,Read,Write} for BufStream`
* `stdin`
* `Stdin`
* `Stdin::lock`
* `Stdin::read_line` - added method
* `StdinLock`
* `Read for Stdin`
* `{Read,BufRead} for StdinLock`
* `stdout`
* `Stdout`
* `Stdout::lock`
* `StdoutLock`
* `Write for Stdout`
* `Write for StdoutLock`
* `stderr`
* `Stderr`
* `Stderr::lock`
* `StderrLock`
* `Write for Stderr`
* `Write for StderrLock`
* `io::Result`
* `io::Error`
* `io::Error::last_os_error`
* `{Display, Error} for Error`
Unstable APIs:
(reasons can be found in the commit itself)
* `Write::flush`
* `Seek`
* `ErrorKind`
* `Error::new`
* `Error::from_os_error`
* `Error::kind`
Deprecated APIs
* `Error::description` - available via the `Error` trait
* `Error::detail` - available via the `Display` implementation
* `thread::Builder::{stdout, stderr}`
Changes in functionality:
* `old_io::stdio::set_stderr` is now a noop as the infrastructure for printing
backtraces has migrated to `std::io`.
* The `ReadExt`, `WriteExt`, and `BufReadExt` extension traits were all removed
by folding functionality into the corresponding trait.
[breaking-change]
This commit stabilizes essentially all of the new `std::path` API. The
API itself is changed in a couple of ways (which brings it in closer
alignment with the RFC):
* `.` components are now normalized away, unless they appear at the
start of a path. This in turn effects the semantics of e.g. asking for
the file name of `foo/` or `foo/.`, both of which yield `Some("foo")`
now. This semantics is what the original RFC specified, and is also
desirable given early experience rolling out the new API.
* The `parent` method is now `without_file` and succeeds if, and only
if, `file_name` is `Some(_)`. That means, in particular, that it fails
for a path like `foo/../`. This change affects `pop` as well.
In addition, the `old_path` module is now deprecated.
[breaking-change]
r? @alexcrichton
This commit stabilizes essentially all of the new `std::path` API. The
API itself is changed in a couple of ways (which brings it in closer
alignment with the RFC):
* `.` components are now normalized away, unless they appear at the
start of a path. This in turn effects the semantics of e.g. asking for
the file name of `foo/` or `foo/.`, both of which yield `Some("foo")`
now. This semantics is what the original RFC specified, and is also
desirable given early experience rolling out the new API.
* The `parent` function now succeeds if, and only if, the path has at
least one non-root/prefix component. This change affects `pop` as
well.
* The `Prefix` component now involves a separate `PrefixComponent`
struct, to better allow for keeping both parsed and unparsed prefix data.
In addition, the `old_path` module is now deprecated.
Closes#23264
[breaking-change]
This commit performs another pass over the `std::char` module for stabilization.
Some minor cleanup is performed such as migrating documentation from libcore to
libunicode (where the `std`-facing trait resides) as well as a slight
reorganiation in libunicode itself. Otherwise, the stability modifications made
are:
* `char::from_digit` is now stable
* `CharExt::is_digit` is now stable
* `CharExt::to_digit` is now stable
* `CharExt::to_{lower,upper}case` are now stable after being modified to return
an iterator over characters. While the implementation today has not changed
this should allow us to implement the full set of case conversions in unicode
where some characters can map to multiple when doing an upper or lower case
mapping.
* `StrExt::to_{lower,upper}case` was added as unstable for a convenience of not
having to worry about characters expanding to more characters when you just
want the whole string to get into upper or lower case.
This is a breaking change due to the change in the signatures of the
`CharExt::to_{upper,lower}case` methods. Code can be updated to use functions
like `flat_map` or `collect` to handle the difference.
[breaking-change]
Closes#20333
This commit performs another pass over the `std::char` module for stabilization.
Some minor cleanup is performed such as migrating documentation from libcore to
libunicode (where the `std`-facing trait resides) as well as a slight
reorganiation in libunicode itself. Otherwise, the stability modifications made
are:
* `char::from_digit` is now stable
* `CharExt::is_digit` is now stable
* `CharExt::to_digit` is now stable
* `CharExt::to_{lower,upper}case` are now stable after being modified to return
an iterator over characters. While the implementation today has not changed
this should allow us to implement the full set of case conversions in unicode
where some characters can map to multiple when doing an upper or lower case
mapping.
* `StrExt::to_{lower,upper}case` was added as unstable for a convenience of not
having to worry about characters expanding to more characters when you just
want the whole string to get into upper or lower case.
This is a breaking change due to the change in the signatures of the
`CharExt::to_{upper,lower}case` methods. Code can be updated to use functions
like `flat_map` or `collect` to handle the difference.
[breaking-change]
This may not be quite ready to go out, I fixed some docs but suspect I missed a bunch.
I also wound up fixing a bunch of redundant `[]` suffixes, but on closer inspection I don't believe that can land until after a snapshot.
Building on #22076, I've added some tests for stable methods in f32 and f64 that didn't have any before.
Please let me know if there are any improvements I can make, and I am happy to make them! 📬
Being a person who somehow has taken a liking to premature optimisation, my knee-jerk reaction to
locking in std handles was preamble resembling following snippet:
let stdout = stdout();
let lstdout = stdout.lock();
let stdin = stdin();
let lstdin = stdin.lock();
and then reading from the locked handle like this:
let mut letter = [0; 1];
lstdin.read(&mut letter).unwrap();
As it is now this code will deadlock because the `read` method attempts to lock stdout as well!
r? @alexcrichton
---
Either way, I find flushing stdout when stdin is used debatable. I believe people who write prompts should take care to flush stdout when necessary themselves.
Another idea: Would be cool if locks on std handles would be taken for a thread, rather than a handle, so given preamble (first code snippet)
stdin.lock()
or more generally
stdin.read(…)
worked fine. I.e. if more than a single lock are all taken inside the same thread, it would work, though not sure if our synchronisation primitives are expressive enough to make it possible.
The `std::net` primitives should be ready for use now and as a result the old
ones are now deprecated and slated for removal. Most TCP/UDP functionality is
now available through `std::net` but the `std::old_io::net::pipe` module is
removed entirely from the standard library.
Unix socket funtionality can be found in sfackler's [`unix_socket`][unix] crate
and there is currently no replacement for named pipes on Windows.
[unix]: https://crates.io/crates/unix_socket
[breaking-change]
The `std::net` primitives should be ready for use now and as a result the old
ones are now deprecated and slated for removal. Most TCP/UDP functionality is
now available through `std::net` but the `std::old_io::net::pipe` module is
removed entirely from the standard library.
Unix socket funtionality can be found in sfackler's [`unix_socket`][unix] crate
and there is currently no replacement for named pipes on Windows.
[unix]: https://crates.io/crates/unix_socket
[breaking-change]
Being a person who somehow has taken a liking to premature optimisation, my knee-jerk reaction to
locking in std handles was preamble resembling following snippet:
let stdout = stdout();
let lstdout = stdout.lock();
let stdin = stdin();
let lstdin = stdin.lock();
and then reading from the locked handle like this:
let mut letter = [0; 1];
lstdin.read(&mut letter).unwrap();
As it is now this code will deadlock because the `read` method attempts to lock stdout as well!
Unstable items used in a macro expansion will now always trigger
stability warnings, *unless* the unstable items are directly inside a
macro marked with `#[allow_internal_unstable]`. IOW, the compiler warns
unless the span of the unstable item is a subspan of the definition of a
macro marked with that attribute.
E.g.
#[allow_internal_unstable]
macro_rules! foo {
($e: expr) => {{
$e;
unstable(); // no warning
only_called_by_foo!();
}}
}
macro_rules! only_called_by_foo {
() => { unstable() } // warning
}
foo!(unstable()) // warning
The unstable inside `foo` is fine, due to the attribute. But the
`unstable` inside `only_called_by_foo` is not, since that macro doesn't
have the attribute, and the `unstable` passed into `foo` is also not
fine since it isn't contained in the macro itself (that is, even though
it is only used directly in the macro).
In the process this makes the stability tracking much more precise,
e.g. previously `println!("{}", unstable())` got no warning, but now it
does. As such, this is a bug fix that may cause [breaking-change]s.
The attribute is definitely feature gated, since it explicitly allows
side-stepping the feature gating system.
---
This updates `thread_local!` macro to use the attribute, since it uses
unstable features internally (initialising a struct with unstable
fields).
This commit performs a stabilization pass over the `std::fs` module now that
it's had some time to bake. The change was largely just adding `#[stable]` tags,
but there are a few APIs that remain `#[unstable]`.
The following apis are now marked `#[stable]`:
* `std::fs` (the name)
* `File`
* `Metadata`
* `ReadDir`
* `DirEntry`
* `OpenOptions`
* `Permissions`
* `File::{open, create}`
* `File::{sync_all, sync_data}`
* `File::set_len`
* `File::metadata`
* Trait implementations for `File` and `&File`
* `OpenOptions::new`
* `OpenOptions::{read, write, append, truncate, create}`
* `OpenOptions::open` - this function was modified, however, to not attempt to
reject cross-platform openings of directories. This means that some platforms
will succeed in opening a directory and others will fail.
* `Metadata::{is_dir, is_file, len, permissions}`
* `Permissions::{readonly, set_readonly}`
* `Iterator for ReadDir`
* `DirEntry::path`
* `remove_file` - like with `OpenOptions::open`, the extra windows code to
remove a readonly file has been removed. This means that removing a readonly
file will succeed on some platforms but fail on others.
* `metadata`
* `rename`
* `copy`
* `hard_link`
* `soft_link`
* `read_link`
* `create_dir`
* `create_dir_all`
* `remove_dir`
* `remove_dir_all`
* `read_dir`
The following apis remain `#[unstable]`.
* `WalkDir` and `walk` - there are many methods by which a directory walk can be
constructed, and it's unclear whether the current semantics are the right
ones. For example symlinks are not handled super well currently. This is now
behind a new `fs_walk` feature.
* `File::path` - this is an extra abstraction which the standard library
provides on top of what the system offers and it's unclear whether we should
be doing so. This is now behind a new `file_path` feature.
* `Metadata::{accessed, modified}` - we do not currently have a good
abstraction for a moment in time which is what these APIs should likely be
returning, so these remain `#[unstable]` for now. These are now behind a new
`fs_time` feature
* `set_file_times` - like with `Metadata::accessed`, we do not currently have
the appropriate abstraction for the arguments here so this API remains
unstable behind the `fs_time` feature gate.
* `PathExt` - the precise set of methods on this trait may change over time and
some methods may be removed. This API remains unstable behind the `path_ext`
feature gate.
* `set_permissions` - we may wish to expose a more granular ability to set the
permissions on a file instead of just a blanket \"set all permissions\" method.
This function remains behind the `fs` feature.
The following apis are now `#[deprecated]`
* The `TempDir` type is now entirely deprecated and is [located on
crates.io][tempdir] as the `tempdir` crate with [its source][github] at
rust-lang/tempdir.
[tempdir]: https://crates.io/crates/tempdir
[github]: https://github.com/rust-lang/tempdir
The stability of some of these APIs has been questioned over the past few weeks
in using these APIs, and it is intentional that the majority of APIs here are
marked `#[stable]`. The `std::fs` module has a lot of room to grow and the
material is [being tracked in a RFC issue][rfc-issue].
[rfc-issue]: rust-lang/rfcs#939
Closes#22879
[breaking-change]
This module is now superseded by the `std::process` module. This module still
has some room to expand to get quite back up to parity with the `old_io`
version, and there is a [tracking issue][issue] for feature requests as well as
known room for expansion.
[issue]: https://github.com/rust-lang/rfcs/issues/941
[breaking-change]
The new `io` module has had some time to bake and this commit stabilizes some of
the utilities associated with it. This commit also deprecates a number of
`std::old_io::util` functions and structures.
These items are now `#[stable]`
* `Cursor`
* `Cursor::{new, into_inner, get_ref, get_mut, position, set_position}`
* Implementations of I/O traits for `Cursor<T>`
* Delegating implementations of I/O traits for references and `Box` pointers
* Implementations of I/O traits for primitives like slices and `Vec<T>`
* `ReadExt::bytes`
* `Bytes` (and impls)
* `ReadExt::chain`
* `Chain` (and impls)
* `ReadExt::take` (and impls)
* `BufReadExt::lines`
* `Lines` (and impls)
* `io::copy`
* `io::{empty, Empty}` (and impls)
* `io::{sink, Sink}` (and impls)
* `io::{repeat, Repeat}` (and impls)
These items remain `#[unstable]`
* Core I/O traits. These may want a little bit more time to bake along with the
commonly used methods like `read_to_end`.
* `BufReadExt::split` - this function may be renamed to not conflict with
`SliceExt::split`.
* `Error` - there are a number of questions about its representation,
`ErrorKind`, and usability.
These items are now `#[deprecated]` in `old_io`
* `LimitReader` - use `take` instead
* `NullWriter` - use `io::sink` instead
* `ZeroReader` - use `io::repeat` instead
* `NullReader` - use `io::empty` instead
* `MultiWriter` - use `broadcast` instead
* `ChainedReader` - use `chain` instead
* `TeeReader` - use `tee` instead
* `copy` - use `io::copy` instead
[breaking-change]
Unstable items used in a macro expansion will now always trigger
stability warnings, *unless* the unstable items are directly inside a
macro marked with `#[allow_internal_unstable]`. IOW, the compiler warns
unless the span of the unstable item is a subspan of the definition of a
macro marked with that attribute.
E.g.
#[allow_internal_unstable]
macro_rules! foo {
($e: expr) => {{
$e;
unstable(); // no warning
only_called_by_foo!();
}}
}
macro_rules! only_called_by_foo {
() => { unstable() } // warning
}
foo!(unstable()) // warning
The unstable inside `foo` is fine, due to the attribute. But the
`unstable` inside `only_called_by_foo` is not, since that macro doesn't
have the attribute, and the `unstable` passed into `foo` is also not
fine since it isn't contained in the macro itself (that is, even though
it is only used directly in the macro).
In the process this makes the stability tracking much more precise,
e.g. previously `println!(\"{}\", unstable())` got no warning, but now it
does. As such, this is a bug fix that may cause [breaking-change]s.
The attribute is definitely feature gated, since it explicitly allows
side-stepping the feature gating system.
---
This updates `thread_local!` macro to use the attribute, since it uses
unstable features internally (initialising a struct with unstable
fields).
This commit performs a stabilization pass over the `std::fs` module now that
it's had some time to bake. The change was largely just adding `#[stable]` tags,
but there are a few APIs that remain `#[unstable]`.
The following apis are now marked `#[stable]`:
* `std::fs` (the name)
* `File`
* `Metadata`
* `ReadDir`
* `DirEntry`
* `OpenOptions`
* `Permissions`
* `File::{open, create}`
* `File::{sync_all, sync_data}`
* `File::set_len`
* `File::metadata`
* Trait implementations for `File` and `&File`
* `OpenOptions::new`
* `OpenOptions::{read, write, append, truncate, create}`
* `OpenOptions::open` - this function was modified, however, to not attempt to
reject cross-platform openings of directories. This means that some platforms
will succeed in opening a directory and others will fail.
* `Metadata::{is_dir, is_file, len, permissions}`
* `Permissions::{readonly, set_readonly}`
* `Iterator for ReadDir`
* `DirEntry::path`
* `remove_file` - like with `OpenOptions::open`, the extra windows code to
remove a readonly file has been removed. This means that removing a readonly
file will succeed on some platforms but fail on others.
* `metadata`
* `rename`
* `copy`
* `hard_link`
* `soft_link`
* `read_link`
* `create_dir`
* `create_dir_all`
* `remove_dir`
* `remove_dir_all`
* `read_dir`
The following apis remain `#[unstable]`.
* `WalkDir` and `walk` - there are many methods by which a directory walk can be
constructed, and it's unclear whether the current semantics are the right
ones. For example symlinks are not handled super well currently. This is now
behind a new `fs_walk` feature.
* `File::path` - this is an extra abstraction which the standard library
provides on top of what the system offers and it's unclear whether we should
be doing so. This is now behind a new `file_path` feature.
* `Metadata::{accessed, modified}` - we do not currently have a good
abstraction for a moment in time which is what these APIs should likely be
returning, so these remain `#[unstable]` for now. These are now behind a new
`fs_time` feature
* `set_file_times` - like with `Metadata::accessed`, we do not currently have
the appropriate abstraction for the arguments here so this API remains
unstable behind the `fs_time` feature gate.
* `PathExt` - the precise set of methods on this trait may change over time and
some methods may be removed. This API remains unstable behind the `path_ext`
feature gate.
* `set_permissions` - we may wish to expose a more granular ability to set the
permissions on a file instead of just a blanket "set all permissions" method.
This function remains behind the `fs` feature.
The following apis are now `#[deprecated]`
* The `TempDir` type is now entirely deprecated and is [located on
crates.io][tempdir] as the `tempdir` crate with [its source][github] at
rust-lang/tempdir.
[tempdir]: https://crates.io/crates/tempdir
[github]: https://github.com/rust-lang/tempdir
The stability of some of these APIs has been questioned over the past few weeks
in using these APIs, and it is intentional that the majority of APIs here are
marked `#[stable]`. The `std::fs` module has a lot of room to grow and the
material is [being tracked in a RFC issue][rfc-issue].
[rfc-issue]: https://github.com/rust-lang/rfcs/issues/939
[breaking-change]
The two main sub-modules, `c_str` and `os_str`, have now had some time to bake
in the standard library. This commits performs a sweep over the modules adding
various stability tags.
The following APIs are now marked `#[stable]`
* `OsString`
* `OsStr`
* `OsString::from_string`
* `OsString::from_str`
* `OsString::new`
* `OsString::into_string`
* `OsString::push` (renamed from `push_os_str`, added an `AsOsStr` bound)
* various trait implementations for `OsString`
* `OsStr::from_str`
* `OsStr::to_str`
* `OsStr::to_string_lossy`
* `OsStr::to_os_string`
* various trait implementations for `OsStr`
* `CString`
* `CStr`
* `NulError`
* `CString::new` - this API's implementation may change as a result of
rust-lang/rfcs#912 but the usage of `CString::new(thing)` looks like it is
unlikely to change. Additionally, the `IntoBytes` bound is also likely to
change but the set of implementors for the trait will not change (despite the
trait perhaps being renamed).
* `CString::from_vec_unchecked`
* `CString::as_bytes`
* `CString::as_bytes_with_nul`
* `NulError::nul_position`
* `NulError::into_vec`
* `CStr::from_ptr`
* `CStr::as_ptr`
* `CStr::to_bytes`
* `CStr::to_bytes_with_nul`
* various trait implementations for `CStr`
The following APIs remain `#[unstable]`
* `OsStr*Ext` traits remain unstable as the organization of `os::platform` is
uncertain still and the traits may change location.
* `AsOsStr` remains unstable as generic conversion traits are likely to be
rethought soon.
The following APIs were deprecated
* `OsString::push_os_str` is now called `push` and takes `T: AsOsStr` instead (a
superset of the previous functionality).
