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]
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]
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]
This commit deprecates the majority of std::old_io::fs in favor of std::fs and
its new functionality. Some functions remain non-deprecated but are now behind a
feature gate called `old_fs`. These functions will be deprecated once
suitable replacements have been implemented.
The compiler has been migrated to new `std::fs` and `std::path` APIs where
appropriate as part of this change.
Rebase and follow-through on work done by @cmr and @aatch.
Implements most of rust-lang/rfcs#560. Errors encountered from the checks during building were fixed.
The checks for division, remainder and bit-shifting have not been implemented yet.
See also PR #20795
cc @Aatch ; cc @nikomatsakis
aarch64-linux-android build has been broken since #22839.
Aarch64 android has _Unwind_GetIPInfo, so re-define this only for arm32 android.
r? @alexcrichton
* The lint visitor's visit_ty method did not recurse, and had a
reference to the now closed#10894
* The newly enabled recursion has only affected the `deprectated` lint
which now detects uses of deprecated items in trait impls and
function return types
* Renamed some references to `CowString` and `CowVec` to `Cow<str>` and
`Cow<[T]>`, respectively, which appear outside of the crate which
defines them
* Replaced a few instances of `InvariantType<T>` with
`PhantomData<Cell<T>>`
* Disabled the `deprecated` lint in several places that
reference/implement traits on deprecated items which will get cleaned
up in the future
* Unfortunately, this means that if a library declares
`#![deny(deprecated)]` and marks anything as deprecated, it will have
to disable the lint for any uses of said item, e.g. any impl the now
deprecated item
For any library that denies deprecated items but has deprecated items
of its own, this is a [breaking-change]
I had originally intended for the lint to ignore uses of deprecated items that are declared in the same crate, but this goes against some previous test cases that expect the lint to capture *all* uses of deprecated items, so I maintained the previous approach to avoid changing the expected behavior of the lint.
Tested locally on OS X, so hopefully there aren't any deprecated item uses behind a `cfg` that I may have missed.
* count_ones/zeros, trailing_ones/zeros return u32, not usize
* rotate_left/right take u32, not usize
* RADIX, MANTISSA_DIGITS, DIGITS, BITS, BYTES are u32, not usize
Doesn't touch pow because there's another PR for it.
[breaking-change]
* The lint visitor's visit_ty method did not recurse, and had a
reference to the now closed#10894
* The newly enabled recursion has only affected the `deprectated` lint
which now detects uses of deprecated items in trait impls and
function return types
* Renamed some references to `CowString` and `CowVec` to `Cow<str>` and
`Cow<[T]>`, respectively, which appear outside of the crate which
defines them
* Replaced a few instances of `InvariantType<T>` with
`PhantomData<Cell<T>>`
* Disabled the `deprecated` lint in several places that
reference/implement traits on deprecated items which will get cleaned
up in the future
* Disabled the `exceeding_bitshifts` lint for
compile-fail/huge-array-simple test so it doesn't shadow the expected
error on 32bit systems
* Unfortunately, this means that if a library declares
`#![deny(deprecated)]` and marks anything as deprecated, it will have
to disable the lint for any uses of said item, e.g. any impl the now
deprecated item
For any library that denies deprecated items but has deprecated items
of its own, this is a [breaking-change]
This is an implementation of RFC 899 and adds stdio functionality to the new
`std::io` module. Details of the API can be found on the RFC, but from a high
level:
* `io::{stdin, stdout, stderr}` constructors are now available. There are also
`*_raw` variants for unbuffered and unlocked access.
* All handles are globally shared (excluding raw variants).
* The stderr handle is no longer buffered.
* All handles can be explicitly locked (excluding the raw variants).
The `print!` and `println!` machinery has not yet been hooked up to these
streams just yet. The `std::fmt::output` module has also not yet been
implemented as part of this commit.
This is an implementation of RFC 899 and adds stdio functionality to the new
`std::io` module. Details of the API can be found on the RFC, but from a high
level:
* `io::{stdin, stdout, stderr}` constructors are now available. There are also
`*_raw` variants for unbuffered and unlocked access.
* All handles are globally shared (excluding raw variants).
* The stderr handle is no longer buffered.
* All handles can be explicitly locked (excluding the raw variants).
The `print!` and `println!` machinery has not yet been hooked up to these
streams just yet. The `std::fmt::output` module has also not yet been
implemented as part of this commit.
Fixes#20978 for supported platforms (i.e. non-Android POSIX).
This uses `backtrace_pcinfo` to inspect the DWARF debug info and list the file and line pairs for given stack frame. Such pair is not unique due to the presence of inlined functions and the updated routine correctly handles this case. The code is modelled after libbacktrace's `backtrace_full` routine.
There is one known issue with this approach. Macros, when invoked, take over the current frame and shadows the file and line pair which has invoked a macro. In particular, this makes many panicking
macros a bit harder to inspect. This really is a debuginfo problem, and the backtrace routine should print them correctly with a correct debuginfo.
Some example trace:
```
thread '<main>' panicked at 'explicit panic', /home/arachneng/Works/git/rust/src/test/run-pass/backtrace-debuginfo.rs:74
stack backtrace:
1: 0xd964702f - sys::backtrace::write::h32d93fffb64131b2yxC
2: 0xd9670202 - panicking::on_panic::h3a4fcb37b873aefeooM
3: 0xd95b396a - rt::unwind::begin_unwind_inner::h576b3df5f626902dJ2L
4: 0xd9eb88df - rt::unwind::begin_unwind::h16852273847167740350
5: 0xd9eb8afb - aux::callback::h15056955655605709172
at /home/arachneng/Works/git/rust/<std macros>:3
at src/test/run-pass/backtrace-debuginfo-aux.rs:15
6: 0xd9eb8caa - outer::h2cf96412459fceb6ema
at src/test/run-pass/backtrace-debuginfo.rs:73
at src/test/run-pass/backtrace-debuginfo.rs:88
7: 0xd9ebab24 - main::h3f701287441442edasa
at src/test/run-pass/backtrace-debuginfo.rs:134
8: 0xd96daba8 - rust_try_inner
9: 0xd96dab95 - rust_try
10: 0xd9671af4 - rt::lang_start::h7da0de9529b4c394liM
11: 0xd8f3aec4 - __libc_start_main
12: 0xd9eb8148 - <unknown>
13: 0xffffffff - <unknown>
```
- Fixed a couple of dead code warnings in std::sys::backtrace.
- Made `backtrace-debuginfo` test a no-op on non-Linux platforms.
- `backtrace-debuginfo` is no longer tested on pretty-rpass.
Fixes#20978 for supported platforms (i.e. non-Android POSIX).
This uses `backtrace_pcinfo` to inspect the DWARF debug info
and list the file and line pairs for given stack frame.
Such pair is not unique due to the presence of inlined functions
and the updated routine correctly handles this case.
The code is modelled after libbacktrace's `backtrace_full` routine.
There is one known issue with this approach. Macros, when invoked,
take over the current frame and shadows the file and line pair
which has invoked a macro. In particular, this makes many panicking
macros a bit harder to inspect. This really is a debuginfo problem,
and the backtrace routine should print them correctly with
a correct debuginfo.
This commit moves `std::env` away from the `std::old_io` error type as well as
the `std::old_path` module. Methods returning an error now return `io::Error`
and methods consuming or returning paths use `std::path` instead of
`std::old_path`. This commit does not yet mark these APIs as `#[stable]`.
This commit also migrates `std::old_io::TempDir` to `std::fs::TempDir` with
essentially the exact same API. This type was added to interoperate with the new
path API and has its own `tempdir` feature.
Finally, this commit reverts the deprecation of `std::os` APIs returning the old
path API types. This deprecation can come back once the entire `std::old_path`
module is deprecated.
[breaking-change]
This commit removes many unnecessary `unsafe impl` blocks as well as pushing the
needed implementations to the lowest level possible. I noticed that the bounds
for `RwLock` are a little off when reviewing #22574 and wanted to ensure that we
had our story straight on these implementations.
This commit moves `std::env` away from the `std::old_io` error type as well as
the `std::old_path` module. Methods returning an error now return `io::Error`
and methods consuming or returning paths use `std::path` instead of
`std::old_path`. This commit does not yet mark these APIs as `#[stable]`.
This commit also migrates `std::old_io::TempDir` to `std::fs::TempDir` with
essentially the exact same API. This type was added to interoperate with the new
path API and has its own `tempdir` feature.
Finally, this commit reverts the deprecation of `std::os` APIs returning the old
path API types. This deprecation can come back once the entire `std::old_path`
module is deprecated.
[breaking-change]
This affects the `set_non_blocking` function which cannot fail for Unix or
Windows, given correct parameters. Additionally, the short UDP write error case
has been removed as there is no such thing as \"short UDP writes\", instead, the
operating system will error out if the application tries to send a packet
larger than the MTU of the network path.
The windows/unix modules were currently inconsistent about the traits being
implemented for `DirEntry` and there isn't much particular reason why the traits
*couldn't* be implemented for `ReadDir` and `DirEntry`, so this commit ensures
that they are implemented.
Closes#22577
This affects the `set_non_blocking` function which cannot fail for Unix or
Windows, given correct parameters. Additionally, the short UDP write error case
has been removed as there is no such thing as "short UDP writes", instead, the
operating system will error out if the application tries to send a packet
larger than the MTU of the network path.
... to convert between Box and raw pointers. E. g. use
```
let b: Box<Foo> = Box::from_raw(p);
```
instead of
```
let b: Box<Foo> = mem::transmute(p);
```
Patch also changes closure release code in `src/libstd/sys/unix/thread.rs`
when `pthread_create` failed. Raw pointer was transmuted to box of
`FnOnce()` instead of `Thunk`. This code was probably never executed,
because `pthread_create` rarely fails in practice.
This commit removes many unnecessary `unsafe impl` blocks as well as pushing the
needed implementations to the lowest level possible. I noticed that the bounds
for `RwLock` are a little off when reviewing #22574 and wanted to ensure that we
had our story straight on these implementations.
The windows/unix modules were currently inconsistent about the traits being
implemented for `DirEntry` and there isn't much particular reason why the traits
*couldn't* be implemented for `ReadDir` and `DirEntry`, so this commit ensures
that they are implemented.
Closes#22577
This commit is an implementation of [RFC 592][r592] and [RFC 840][r840]. These
two RFCs tweak the behavior of `CString` and add a new `CStr` unsized slice type
to the module.
[r592]: https://github.com/rust-lang/rfcs/blob/master/text/0592-c-str-deref.md
[r840]: https://github.com/rust-lang/rfcs/blob/master/text/0840-no-panic-in-c-string.md
The new `CStr` type is only constructable via two methods:
1. By `deref`'ing from a `CString`
2. Unsafely via `CStr::from_ptr`
The purpose of `CStr` is to be an unsized type which is a thin pointer to a
`libc::c_char` (currently it is a fat pointer slice due to implementation
limitations). Strings from C can be safely represented with a `CStr` and an
appropriate lifetime as well. Consumers of `&CString` should now consume `&CStr`
instead to allow producers to pass in C-originating strings instead of just
Rust-allocated strings.
A new constructor was added to `CString`, `new`, which takes `T: IntoBytes`
instead of separate `from_slice` and `from_vec` methods (both have been
deprecated in favor of `new`). The `new` method returns a `Result` instead of
panicking. The error variant contains the relevant information about where the
error happened and bytes (if present). Conversions are provided to the
`io::Error` and `old_io::IoError` types via the `FromError` trait which
translate to `InvalidInput`.
This is a breaking change due to the modification of existing `#[unstable]` APIs
and new deprecation, and more detailed information can be found in the two RFCs.
Notable breakage includes:
* All construction of `CString` now needs to use `new` and handle the outgoing
`Result`.
* Usage of `CString` as a byte slice now explicitly needs a `.as_bytes()` call.
* The `as_slice*` methods have been removed in favor of just having the
`as_bytes*` methods.
Closes#22469Closes#22470
[breaking-change]
This commit is an implementation of [RFC 592][r592] and [RFC 840][r840]. These
two RFCs tweak the behavior of `CString` and add a new `CStr` unsized slice type
to the module.
[r592]: https://github.com/rust-lang/rfcs/blob/master/text/0592-c-str-deref.md
[r840]: https://github.com/rust-lang/rfcs/blob/master/text/0840-no-panic-in-c-string.md
The new `CStr` type is only constructable via two methods:
1. By `deref`'ing from a `CString`
2. Unsafely via `CStr::from_ptr`
The purpose of `CStr` is to be an unsized type which is a thin pointer to a
`libc::c_char` (currently it is a fat pointer slice due to implementation
limitations). Strings from C can be safely represented with a `CStr` and an
appropriate lifetime as well. Consumers of `&CString` should now consume `&CStr`
instead to allow producers to pass in C-originating strings instead of just
Rust-allocated strings.
A new constructor was added to `CString`, `new`, which takes `T: IntoBytes`
instead of separate `from_slice` and `from_vec` methods (both have been
deprecated in favor of `new`). The `new` method returns a `Result` instead of
panicking. The error variant contains the relevant information about where the
error happened and bytes (if present). Conversions are provided to the
`io::Error` and `old_io::IoError` types via the `FromError` trait which
translate to `InvalidInput`.
This is a breaking change due to the modification of existing `#[unstable]` APIs
and new deprecation, and more detailed information can be found in the two RFCs.
Notable breakage includes:
* All construction of `CString` now needs to use `new` and handle the outgoing
`Result`.
* Usage of `CString` as a byte slice now explicitly needs a `.as_bytes()` call.
* The `as_slice*` methods have been removed in favor of just having the
`as_bytes*` methods.
Closes#22469Closes#22470
[breaking-change]
This commit is an implementation of [RFC 823][rfc] which is another pass over
the `std::hash` module for stabilization. The contents of the module were not
entirely marked stable, but some portions which remained quite similar to the
previous incarnation are now marked `#[stable]`. Specifically:
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0823-hash-simplification.md
* `std::hash` is now stable (the name)
* `Hash` is now stable
* `Hash::hash` is now stable
* `Hasher` is now stable
* `SipHasher` is now stable
* `SipHasher::new` and `new_with_keys` are now stable
* `Hasher for SipHasher` is now stable
* Many `Hash` implementations are now stable
All other portions of the `hash` module remain `#[unstable]` as they are less
commonly used and were recently redesigned.
This commit is a breaking change due to the modifications to the `std::hash` API
and more details can be found on the [RFC][rfc].
Closes#22467
[breaking-change]
