... 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 is not a complete implementation of the RFC:
- only existing methods got updated, no new ones added
- doc comments are not extensive enough yet
- optimizations got lost and need to be reimplemented
See https://github.com/rust-lang/rfcs/pull/528
Technically a
[breaking-change]
* Adds features and allows
* Removes unused muts, unused imports, dead code
* Migrates some deprecated code to new io/env
* Changes std::num::uint/int to be re-exports of std::num::usize/isize
libcollections, liballoc, and libcoretest no longer warn during testing.
libstd warns much less, though there's some dangly bits that weren't obvious fixes. In particular, how to only supress deprecated warnings in specific submodules of std.
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 stabilizes `std::borrow`, making the following modifications
to catch up the API with language changes:
* It renames `BorrowFrom` to `Borrow`, as was originally intended (but
blocked for technical reasons), and reorders the parameters
accordingly.
* It moves the type parameter of `ToOwned` to an associated type. This
is somewhat less flexible, in that each borrowed type must have a
unique owned type, but leads to a significant simplification for
`Cow`. Flexibility can be regained by using newtyped slices, which is
advisable for other reasons anyway.
* It removes the owned type parameter from `Cow`, making the type much
less verbose.
* Deprecates the `is_owned` and `is_borrowed` predicates in favor of
direct matching.
The above API changes are relatively minor; the basic functionality
remains the same, and essentially the whole module is now marked
`#[stable]`.
[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]
This overlaps with #22276 (I left make check running overnight) but covers a number of additional cases and has a few rewrites where the clones are not even necessary.
This also implements `RandomAccessIterator` for `iter::Cloned`
cc @steveklabnik, you may want to glance at this before #22281 gets the bors treatment
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 breaks all implementors of FromIterator, as they must now accept IntoIterator instead of Iterator. The fix for this is generally trivial (change the bound, and maybe call into_iter() on the argument to get the old argument).
Users of FromIterator should be unaffected because Iterators are IntoIterator.
[breaking-change]
This breaks all implementors of Extend, as they must now accept IntoIterator instead of Iterator. The fix for this is generally trivial (change the bound, and maybe call into_iter() on the argument to get the old argument).
Users of Extend should be unaffected because Iterators are IntoIterator.
[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]
Now that the necessary associated types exist for the `IntoIterator` trait this
commit stabilizes the trait as-is as well as all existing implementations.
The `connect_error` test check if connecting to "0.0.0.0:1" works (it
shouldn't). And in case of error, the test expects a `ConnectionRefused`
error.
Under OpenBSD, trying to connect to "0.0.0.0" isn't a `ConnectionRefused`:
it is an `InvalidInput` error.
The patch allow the error to be `ConnectionRefused` or `InvalidInput`.
Another possibility is to check connecting to "127.0.0.1:1" and expects only `ConnectionRefused` error.
This commit exposes the `is_sep` function and `MAIN_SEP` constant, as
well as Windows path prefixes. The path prefix enum is safely exposed on
all platforms, but it only yielded as a component for Windows.
Exposing the prefix enum as part of prefix components involved changing
the type from `OsStr` to the `Prefix` enum, which is a:
[breaking-change]
* Move the type parameter on the `AsciiExt` trait to an associated type named
`Owned`.
* Move `ascii::escape_default` to using an iterator.
This is a breaking change due to the removal of the type parameter on the
`AsciiExt` trait as well as the modifications to the `escape_default` function
to returning an iterator. Manual implementations of `AsciiExt` (or `AsciiExt`
bounds) should be adjusted to remove the type parameter and using the new
`escape_default` should be relatively straightforward.
[breaking-change]
This commit makes several changes to `std::thread` in preparation for
final stabilization:
* It removes the ability to handle panics from `scoped` children; see
#20807 for discussion
* It adds a `JoinHandle` structure, now returned from `spawn`, which
makes it possible to join on children that do not share data from
their parent's stack. The child is automatically detached when the
handle is dropped, and the handle cannot be copied due to Posix
semantics.
* It moves all static methods from `std:🧵:Thread` to free
functions in `std::thread`. This was done in part because, due to the
above changes, there are effectively no direct `Thread` constructors,
and the static methods have tended to feel a bit awkward.
* Adds an `io::Result` around the `Builder` methods `scoped` and
`spawn`, making it possible to handle OS errors when creating
threads. The convenience free functions entail an unwrap.
* Stabilizes the entire module. Despite the fact that the API is
changing somewhat here, this is part of a long period of baking and
the changes are addressing all known issues prior to alpha2. If
absolutely necessary, further breaking changes can be made prior to beta.
Closes#20807
[breaking-change]
This commit renames the features for the `std::old_io` and `std::old_path`
modules to `old_io` and `old_path` to help facilitate migration to the new APIs.
This is a breaking change as crates which mention the old feature names now need
to be renamed to use the new feature names.
[breaking-change]
This commit performs a stabilization pass over the `std::ascii` module taking
the following actions:
* the module name is now stable
* `AsciiExt` is now stable after moving its type parameter to an `Owned`
associated type
* `AsciiExt::is_ascii` is now stable
* `AsciiExt::to_ascii_uppercase` is now stable
* `AsciiExt::to_ascii_lowercase` is now stable
* `AsciiExt::eq_ignore_ascii_case` is now stable
* `AsciiExt::make_ascii_uppercase` is added to possibly replace
`OwnedAsciiExt::into_ascii_uppercase` (similarly for lowercase variants).
* `escape_default` now returns an iterator and is stable
* `EscapeDefault` is now stable
Trait implementations are now also marked stable.
Primarily it is still unstable to *implement* the `AsciiExt` trait due to it
containing some unstable methods.
[breaking-change]
In most places this preserves the current API by adding an explicit
`'static` bound.
Notably absent are some impls like `unsafe impl<T: Send> Send for
Foo<T>` and the `std::thread` module. It is likely that it will be
possible to remove these after auditing the code to ensure restricted
lifetimes are safe.
More progress on #22251.
- Now "make check-stage2-T-aarch64-linux-android-H-x86_64-unknown-linux-gnu" works (#21773)
- Fix & enable debuginfo tests for android (#10381)
- Fix & enable more tests for android (both for arm/aarch64)
- Enable many already-pass tests on android (both for arm/aarch64)
Now that the necessary associated types exist for the `IntoIterator` trait this
commit stabilizes the trait as-is as well as all existing implementations.
Some examples for `std::num::Float`
~~This is WIP for making examples for `f32`. This probably won't pass `make tidy` and I'm not sure which `f32` needs documentation. https://github.com/rust-lang/rust/issues/22025 shows 2 sets of `f32` which seems split between `core` and `std`. I'm not sure which should be documented but I started doing a couple from `std`. Easy to move if that's where they go...~~
~~Gotta build it eventually to actually see if the docs actually appear where I think they will or if I'm just disillusioned.~~
cc @steveklabnik
The test \"signal_reported_right\" send a signal `1` to `/bin/sh`, and check
the status code to check if the signal is reported right.
Under OpenBSD, the signal `1` (`SIGHUP`) is catched by `/bin/sh`,
resulting the test failed.
Use the uncatchable signal `9` (`SIGKILL`) for test.
This commit mostly replaces some of the uses of os::args with env::args.
This, for obvious reasons is based on top of #22400. Do not r+ before that lands.
The connect_error test check if connecting to "0.0.0.0:1" works (it
shouldn't). And in case of error, the test expects a ConnectionRefused
error.
Under OpenBSD, trying to connect to "0.0.0.0" isn't a ConnectionRefused:
it is an InvalidInput error.
The patch allow the error to be ConnectionRefused or InvalidInput.
Changes std::os::errno to return i32, the return type used by the function being delegated to.
This is my first contribution, so feel free to give me advice. I'll be happy to correct things.
`IntoIterator` now has an extra associated item:
``` rust
trait IntoIterator {
type Item;
type IntoIter: Iterator<Self=Self::Item>;
}
```
This lets you bind the iterator \"`Item`\" directly when writing generic functions:
``` rust
// hypothetical change, not included in this PR
impl Extend<T> for Vec<T> {
// you can now write
fn extend<I>(&mut self, it: I) where I: IntoIterator<Item=T> { .. }
// instead of
fn extend<I: IntoIterator>(&mut self, it: I) where I::IntoIter: Iterator<Item=T> { .. }
}
```
The downside is that now you have to write an extra associated type in your `IntoIterator` implementations:
``` diff
impl<T> IntoIterator for Vec<T> {
+ type Item = T;
type IntoIter = IntoIter<T>;
fn into_iter(self) -> IntoIter<T> { .. }
}
```
Because this breaks all downstream implementations of `IntoIterator`, this is a [breaking-change]
---
r? @aturon
This snuck through my refactor.
Would it be worth the effort to have a test pass that attempts to lint the code for all targets, even if it's not feasible to actually build and test it?
`pipe(2)`, under FreeBSD and OpenBSD return a bidirectionnal pipe. So
reading from the writer would block (waiting data) instead of returning
an error.
like for FreeBSD, disable the test for OpenBSD.
Rather than stabilize on the current API, we're going to punt this
concern to crates.io, to allow for faster iteration.
If you need this functionality, you might look at https://github.com/carllerche/syncbox
[breaking-change]
This commit exposes the `is_sep` function and `MAIN_SEP` constant, as
well as Windows path prefixes. The path prefix enum is safely exposed on
all platforms, but it only yielded as a component for Windows.
Exposing the prefix enum as part of prefix components involved changing
the type from `OsStr` to the `Prefix` enum, which is a:
[breaking-change]
The test "signal_reported_right" send a signal `1` to `/bin/sh`, and check
the status code to check if the signal is reported right.
Under OpenBSD, the signal `1` (`SIGHUP`) is catched by `/bin/sh`,
resulting the test failed.
Use the uncatchable signal `9` (`SIGKILL`) for test.
This PR replaces uses of `os::getenv` with newly introduced `env::var{,_os}`.
Mostly did this as a background activity to procrastinate from procrastinating.
Tests appear to build and run fine. This includes benchmarks from test/bench directory.
Some function signatures have changed, so this is a [breaking-change].
In particular, radixes and numerical values of digits are represented by `u32` now.
Part of #22240
`PathBuf` does implement `Hash`, but `Path` doesn't. This makes it
annoying if you have a `HashMap` with `PathBuf`s as keys, because
it means you have to convert a `Path` into a `PathBuf` and get a
reference to it simply to perform operations on the `HashMap`!
`PathBuf` does implement `Hash`, but `Path` doesn't. This makes it
annoying if you have a `HashMap` with `PathBuf`s as keys, because
it means you have to convert a `Path` into a `PathBuf` and get a
reference to it simply to perform operations on the `HashMap`!
Per [RFC 579](https://github.com/rust-lang/rfcs/pull/579), this commit
adds a new `std::process` module. This module is largely based on the
existing `std::old_io::process` module, but refactors the API to use
`OsStr` and other new standards set out by IO reform.
The existing module is not yet deprecated, to allow for the new API to
get a bit of testing before a mass migration to it.
This commit is an implementation of [RFC 807][rfc] which adds a `std::net`
module for basic neworking based on top of `std::io`. This module serves as a
replacement for the `std::old_io::net` module and networking primitives in
`old_io`.
[rfc]: fillmein
The major focus of this redesign is to cut back on the level of abstraction to
the point that each of the networking types is just a bare socket. To this end
functionality such as timeouts and cloning has been removed (although cloning
can be done through `duplicate`, it may just yield an error).
With this `net` module comes a new implementation of `SocketAddr` and `IpAddr`.
This work is entirely based on #20785 and the only changes were to alter the
in-memory representation to match the `libc`-expected variants and to move from
public fields to accessors.
This commit is an implementation of [RFC 807][rfc] which adds a `std::net`
module for basic neworking based on top of `std::io`. This module serves as a
replacement for the `std::old_io::net` module and networking primitives in
`old_io`.
[rfc]: fillmein
The major focus of this redesign is to cut back on the level of abstraction to
the point that each of the networking types is just a bare socket. To this end
functionality such as timeouts and cloning has been removed (although cloning
can be done through `duplicate`, it may just yield an error).
With this `net` module comes a new implementation of `SocketAddr` and `IpAddr`.
This work is entirely based on #20785 and the only changes were to alter the
in-memory representation to match the `libc`-expected variants and to move from
public fields to accessors.
This commit tweaks the interface of the `std::env` module to make it more
ergonomic for common usage:
* `env::var` was renamed to `env::var_os`
* `env::var_string` was renamed to `env::var`
* `env::args` was renamed to `env::args_os`
* `env::args` was re-added as a panicking iterator over string values
* `env::vars` was renamed to `env::vars_os`
* `env::vars` was re-added as a panicking iterator over string values.
This should make common usage (e.g. unicode values everywhere) more ergonomic
as well as "the default". This is also a breaking change due to the differences
of what's yielded from each of these functions, but migration should be fairly
easy as the defaults operate over `String` which is a common type to use.
[breaking-change]
There are a number of holes that the stability lint did not previously cover,
including:
* Types
* Bounds on type parameters on functions and impls
* Where clauses
* Imports
* Patterns (structs and enums)
These holes have all been fixed by overriding the `visit_path` function on the
AST visitor instead of a few specialized cases. This change also necessitated a
few stability changes:
* The `collections::fmt` module is now stable (it was already supposed to be).
* The `thread_local:👿:Key` type is now stable (it was already supposed to
be).
* The `std::rt::{begin_unwind, begin_unwind_fmt}` functions are now stable.
These are required via the `panic!` macro.
* The `std::old_io::stdio::{println, println_args}` functions are now stable.
These are required by the `print!` and `println!` macros.
* The `ops::{FnOnce, FnMut, Fn}` traits are now `#[stable]`. This is required to
make bounds with these traits stable. Note that manual implementations of
these traits are still gated by default, this stability only allows bounds
such as `F: FnOnce()`.
Closes#8962Closes#16360Closes#20327
This commit tweaks the interface of the `std::env` module to make it more
ergonomic for common usage:
* `env::var` was renamed to `env::var_os`
* `env::var_string` was renamed to `env::var`
* `env::args` was renamed to `env::args_os`
* `env::args` was re-added as a panicking iterator over string values
* `env::vars` was renamed to `env::vars_os`
* `env::vars` was re-added as a panicking iterator over string values.
This should make common usage (e.g. unicode values everywhere) more ergonomic
as well as "the default". This is also a breaking change due to the differences
of what's yielded from each of these functions, but migration should be fairly
easy as the defaults operate over `String` which is a common type to use.
[breaking-change]
There are a number of holes that the stability lint did not previously cover,
including:
* Types
* Bounds on type parameters on functions and impls
* Where clauses
* Imports
* Patterns (structs and enums)
These holes have all been fixed by overriding the `visit_path` function on the
AST visitor instead of a few specialized cases. This change also necessitated a
few stability changes:
* The `collections::fmt` module is now stable (it was already supposed to be).
* The `thread_local:👿:Key` type is now stable (it was already supposed to
be).
* The `std::rt::{begin_unwind, begin_unwind_fmt}` functions are now stable.
These are required via the `panic!` macro.
* The `std::old_io::stdio::{println, println_args}` functions are now stable.
These are required by the `print!` and `println!` macros.
* The `ops::{FnOnce, FnMut, Fn}` traits are now `#[stable]`. This is required to
make bounds with these traits stable. Note that manual implementations of
these traits are still gated by default, this stability only allows bounds
such as `F: FnOnce()`.
Additionally, the compiler now has special logic to ignore its own generated
`__test` module for the `--test` harness in terms of stability.
Closes#8962Closes#16360Closes#20327
[breaking-change]
I was working on adding examples to the documentation in `std::num::Float`. I got to `exp2`, which says "Returns 2 raised to the power of the number, `2^(self)`."
So I tried running this code:
```
use std::num::Float;
#[test]
fn test_exp2() {
assert_eq!(32.0, 5.0.exp2());
}
```
and it resulted in a failure of `(left: `32`, right: `148.413159`)`. That 148.413159 is the value for e^5, which is `exp()`, not `exp2()`.
Sure enough, `exp2` is calling `exp` and shouldn't be, looks like a copy-paste error.
I haven't added any tests for this since it's unlikely to break again, but I will happily do so if people think that would be a good idea. The doc examples are coming :)
I scanned through the other functions in these files for similar sorts of errors and didn't notice any.
* Remove type parameters from `IteratorExt::cloned`
* Rename `IntoIterator::Iter` to `IntoIterator::IntoIter`
* Mark `IntoIterator::into_iter` as stable (but not the trait, only the method).
Rename several remaining `Show`s to Debug, `String`s to Display (mostly in comments and docs).
Update reference.md:
- derive() no longer supports Zero trait
- derive() now supports Copy trait
This commit is an implementation of [RFC 739][rfc] which adds a new `std::fs`
module to the standard library. This module provides much of the same
functionality as `std::old_io::fs` but it has many tweaked APIs as well as uses
the new `std::path` module.
[rfc]: https://github.com/rust-lang/rfcs/pull/739
This commit is an implementation of [RFC 739][rfc] which adds a new `std::fs`
module to the standard library. This module provides much of the same
functionality as `std::old_io::fs` but it has many tweaked APIs as well as uses
the new `std::path` module.
[rfc]: https://github.com/rust-lang/rfcs/pull/739
This is in preparation for stabilization of the `IntoIterator` trait. All
implementations and references to `Iter` need to be renamed to `IntoIter`.
[breaking-change]
New functions, `slice::from_raw_parts` and `slice::from_raw_parts_mut`,
are added to implement the lifetime convention as agreed in rust-lang/rfcs#556.
The functions `slice::from_raw_buf` and `slice::from_raw_mut_buf` are
left deprecated for the time being.
Holding back on changing the signature of `std::ffi::c_str_to_bytes` as consensus in rust-lang/rfcs#592 is building to replace it with a composition of other functions.
Contribution to #21923.
This is 99% burning ints to the ground, but I also got rid of useless annotations or made code more \"idiomatic\" as I went along. Mostly changes in tests.
This was particularly helpful in the time just after OIBIT's
implementation to make sure things that were supposed to be Copy
continued to be, but it's now creates a lot of noise for types that
intentionally don't want to be Copy.
r? @alexcrichton
This also removes two erroneous re-exports of the Entry variants, and so is incidentally a [breaking-change], though presumably no one should have been using those.
r? @aturon
- add `_SC_GETPW_R_SIZE_MAX` constant
- declare `struct passwd`
- convert `load_self` to `current_exe`
Note: OpenBSD don't provide system function to return a valuable Path
for `env::current_exe`. The implementation is currently based on the
value of `argv[0]`, which couldn't be used when executable is called via
PATH.
- add `_SC_GETPW_R_SIZE_MAX` constant
- declare `struct passwd`
- convert `load_self` to `current_exe`
Note: OpenBSD don't provide system function to return a valuable Path
for `env::current_exe`. The implementation is currently based on the
value of `argv[0]`, which couldn't be used when executable is called via
PATH.
New functions, slice::from_raw_parts and slice::from_raw_parts_mut,
are added to implement the lifetime convention as agreed in RFC PR #556.
The functions slice::from_raw_buf and slice::from_raw_mut_buf are
left deprecated for the time being.
`{` and `}` aren’t valid characters on ARM, so this makes Unicode characters render as, e.g., `$u38d$` instead of `$u{38d}`.
This also fixes a small bug where `)` (**r**ight **p**arenthesis) and `*` (**r**aw **p**ointer) would both mangle to `$RP$`, making `)` show up as `*` in backtraces.
This was particularly helpful in the time just after OIBIT's
implementation to make sure things that were supposed to be Copy
continued to be, but it's now creates a lot of noise for types that
intentionally don't want to be Copy.
Currently, if a `#![staged_api]` crate contains an exported item without a stability marker (or inherited stability),
the item is useless.
This change introduces a check to ensure that all exported items have a defined stability.
it also introduces the `unmarked_api` feature, which lets users import unmarked features. While this PR should in theory forbid these from existing,
in practice we can't be so sure; so this lets users bypass this check instead of having to wait for the library and/or compiler to be fixed (since otherwise this is a hard error).
r? @aturon
`{` and `}` aren’t valid characters on ARM.
This also fixes a small bug where `)` (**r**ight **p**arenthesis) and `*`
(**r**aw **p**ointer) would both mangle to `$RP$`, making `)` show up as `*` in
backtraces.
This commit is an implementation of [RFC 576][rfc] which adds back the `std::io`
module to the standard library. No functionality in `std::old_io` has been
deprecated just yet, and the new `std::io` module is behind the same `io`
feature gate.
[rfc]: https://github.com/rust-lang/rfcs/pull/576
A good bit of functionality was copied over from `std::old_io`, but many tweaks
were required for the new method signatures. Behavior such as precisely when
buffered objects call to the underlying object may have been tweaked slightly in
the transition. All implementations were audited to use composition wherever
possible. For example the custom `pos` and `cap` cursors in `BufReader` were
removed in favor of just using `Cursor<Vec<u8>>`.
A few liberties were taken during this implementation which were not explicitly
spelled out in the RFC:
* The old `LineBufferedWriter` is now named `LineWriter`
* The internal representation of `Error` now favors OS error codes (a
0-allocation path) and contains a `Box` for extra semantic data.
* The io prelude currently reexports `Seek` as `NewSeek` to prevent conflicts
with the real prelude reexport of `old_io::Seek`
* The `chars` method was moved from `BufReadExt` to `ReadExt`.
* The `chars` iterator returns a custom error with a variant that explains that
the data was not valid UTF-8.
Implements [RFC 474](https://github.com/rust-lang/rfcs/pull/474); see
that RFC for details/motivation for this change.
This initial commit does not include additional normalization or
platform-specific path extensions. These will be done in follow up
commits or PRs.
Use the crates.io crate `rand` (version 0.1 should be a drop in
replacement for `std::rand`) and `rand_macros` (`#[derive_Rand]` should
be a drop-in replacement).
[breaking-change]
As part of [RFC 474](https://github.com/rust-lang/rfcs/pull/474), this
commit renames `std::path` to `std::old_path`, leaving the existing path
API in place to ease migration to the new one. Updating should be as
simple as adjusting imports, and the prelude still maps to the old path
APIs for now.
[breaking-change]
This commit is an implementation of [RFC 576][rfc] which adds back the `std::io`
module to the standard library. No functionality in `std::old_io` has been
deprecated just yet, and the new `std::io` module is behind the same `io`
feature gate.
[rfc]: https://github.com/rust-lang/rfcs/pull/576
A good bit of functionality was copied over from `std::old_io`, but many tweaks
were required for the new method signatures. Behavior such as precisely when
buffered objects call to the underlying object may have been tweaked slightly in
the transition. All implementations were audited to use composition wherever
possible. For example the custom `pos` and `cap` cursors in `BufReader` were
removed in favor of just using `Cursor<Vec<u8>>`.
A few liberties were taken during this implementation which were not explicitly
spelled out in the RFC:
* The old `LineBufferedWriter` is now named `LineWriter`
* The internal representation of `Error` now favors OS error codes (a
0-allocation path) and contains a `Box` for extra semantic data.
* The io prelude currently reexports `Seek` as `NewSeek` to prevent conflicts
with the real prelude reexport of `old_io::Seek`
* The `chars` method was moved from `BufReadExt` to `ReadExt`.
* The `chars` iterator returns a custom error with a variant that explains that
the data was not valid UTF-8.
I’d kind of like to be able to use HashState in AnyMap, which I can’t do without a stability attribute on it. While I was at it I looked around and found a few more missing.
Now that associated types are fully implemented the iterator adaptors only need
type parameters which are associated with actual storage. All other type
parameters can either be derived from these (e.g. they are an associated type)
or can be bare on the `impl` block itself.
This is a breaking change due to the removal of type parameters on these
iterator adaptors, but code can fairly easily migrate by just deleting the
relevant type parameters for each adaptor. Other behavior should not be
affected.
Closes#21839
[breaking-change]
Hi.
Here a commit in order to add OpenBSD support to rust.
- tests status:
run-pass: test result: ok. 1879 passed; 0 failed; 24 ignored; 0 measured
run-fail: test result: ok. 81 passed; 0 failed; 5 ignored; 0 measured
compile-fail: test result: ok. 1634 passed; 0 failed; 22 ignored; 0 measured
run-pass-fulldeps: test result: ok. 22 passed; 0 failed; 1 ignored; 0 measured
compile-fail-fulldeps: test result: ok. 13 passed; 0 failed; 0 ignored; 0 measured
- The current implementation of load_self function (src/libstd/sys/unix/os.rs) isn't optimal as under OpenBSD I haven't found a reliable method to get the filename of a running process. The current implementation is enought for bootstrapping purpose.
- I have disable `run-pass/tcp-stress.rs` test under openbsd. When run manually, the test pass, but when run under `compiletest`, it timeout and echo continuoulsy `Too many open files`.
- For building with jemalloc, a more recent version of jemalloc would be mandatory. See https://github.com/jemalloc/jemalloc/pull/188 for more details.
Now that associated types are fully implemented the iterator adaptors only need
type parameters which are associated with actual storage. All other type
parameters can either be derived from these (e.g. they are an associated type)
or can be bare on the `impl` block itself.
This is a breaking change due to the removal of type parameters on these
iterator adaptors, but code can fairly easily migrate by just deleting the
relevant type parameters for each adaptor. Other behavior should not be
affected.
Closes#21839
[breaking-change]
This is an implementation of [RFC 578][rfc] which adds a new `std::env` module
to replace most of the functionality in the current `std::os` module. More
details can be found in the RFC itself, but as a summary the following methods
have all been deprecated:
[rfc]: https://github.com/rust-lang/rfcs/pull/578
* `os::args_as_bytes` => `env::args`
* `os::args` => `env::args`
* `os::consts` => `env::consts`
* `os::dll_filename` => no replacement, use `env::consts` directly
* `os::page_size` => `env::page_size`
* `os::make_absolute` => use `env::current_dir` + `join` instead
* `os::getcwd` => `env::current_dir`
* `os::change_dir` => `env::set_current_dir`
* `os::homedir` => `env::home_dir`
* `os::tmpdir` => `env::temp_dir`
* `os::join_paths` => `env::join_paths`
* `os::split_paths` => `env::split_paths`
* `os::self_exe_name` => `env::current_exe`
* `os::self_exe_path` => use `env::current_exe` + `pop`
* `os::set_exit_status` => `env::set_exit_status`
* `os::get_exit_status` => `env::get_exit_status`
* `os::env` => `env::vars`
* `os::env_as_bytes` => `env::vars`
* `os::getenv` => `env::var` or `env::var_string`
* `os::getenv_as_bytes` => `env::var`
* `os::setenv` => `env::set_var`
* `os::unsetenv` => `env::remove_var`
Many function signatures have also been tweaked for various purposes, but the
main changes were:
* `Vec`-returning APIs now all return iterators instead
* All APIs are now centered around `OsString` instead of `Vec<u8>` or `String`.
There is currently on convenience API, `env::var_string`, which can be used to
get the value of an environment variable as a unicode `String`.
All old APIs are `#[deprecated]` in-place and will remain for some time to allow
for migrations. The semantics of the APIs have been tweaked slightly with regard
to dealing with invalid unicode (panic instead of replacement).
The new `std::env` module is all contained within the `env` feature, so crates
must add the following to access the new APIs:
#![feature(env)]
[breaking-change]
- the specific block for dl* function isn't need for openbsd if libdl
isn't marked to be linked here. remove them.
- remove the linkage for libdl: it should already specified in `rtdeps.rs`.
the code of `dynamic_lib.rs` include libdl for:
- linux (already defined in rtdeps.rs)
- android (already defined in rtdeps.rs)
- macos (not needed for macos)
- ios (probably the same as macos)
- freebsd (libdl is a stub)
- dragonfly (libdl is a stub)
- consolidate target_record_sp_limit and target_get_sp_limit functions
for aarch64, powerpc, arm-ios and openbsd as there are all without
segmented stacks (no need to duplicate functions).
- rename __load_self function to rust_load_self
- use a mutex inner load_self() as underline implementation is not thread-safe
