| Age | Commit message (Collapse) | Author | Lines |
|---|
|
std: Allow ?Sized parameters in std::io::copy
|
|
|
|
|
|
The replacements are functions that usually use a single `mem::transmute` in their body and restrict input and output via more concrete types than `T` and `U`. Worth noting are the `transmute` functions for slices and the `from_utf8*` family for mutable slices. Additionally, `mem::transmute` was often used for casting raw pointers, when you can already cast raw pointers just fine with `as`.
This builds upon #27233.
|
|
The investigation into #14232 discovered that it's possible that signal delivery
to a newly spawned process is racy on OSX. This test has been failing spuriously
on the OSX bots for some time now, so ignore it as we don't currently know a
solution and it looks like it may be out of our control.
|
|
std::io::copy did not allow passing trait objects directly (only with an
extra &mut wrapping).
|
|
This reverts commit febdc3b201bcce1546c88e3be1b956d3f90d3059.
|
|
|
|
Also fixes a few outdated links.
|
|
|
|
|
|
The replacements are functions that usually use a single `mem::transmute` in
their body and restrict input and output via more concrete types than `T` and
`U`. Worth noting are the `transmute` functions for slices and the `from_utf8*`
family for mutable slices. Additionally, `mem::transmute` was often used for
casting raw pointers, when you can already cast raw pointers just fine with
`as`.
|
|
This speeds up rustc on #25916 from 1.36Â0.022s to 1.326Â0.025s
|
|
|
|
- Successful merges: #27546, #27550
- Failed merges:
|
|
|
|
|
|
|
|
|
|
This commit is an implementation of [RFC 1184][rfc] which tweaks the behavior of
the `#![no_std]` attribute and adds a new `#![no_core]` attribute. The
`#![no_std]` attribute now injects `extern crate core` at the top of the crate
as well as the libcore prelude into all modules (in the same manner as the
standard library's prelude). The `#![no_core]` attribute disables both std and
core injection.
[rfc]: https://github.com/rust-lang/rfcs/pull/1184
Closes #27394
|
|
Add a new method `CommandExt::session_leader(&mut self, on: bool)` to create a new session (cf. `setsid(2)`) for the child process. This means that the child is the leader of a new process group. The parent process remains the child reaper of the new process.
This is not enough to create a daemon process. The *init* process should be the child reaper of a daemon. This can be achieved if the parent process exit. Moreover, a daemon should not have a controlling terminal. To acheive this, a session leader (the child) must spawn another process (the daemon) in the same session.
cc rust-lang/rfcs#941
cc #17176
|
|
This commit removes the injection of `std::env::args()` from `--test` expanded
code, relying on the test runner itself to call this funciton. This is more
hygienic because we can't assume that `std` exists at the top layer all the
time, and it meaks the injected test module entirely self contained.
|
|
The investigation into #14232 discovered that it's possible that signal delivery
to a newly spawned process is racy on OSX. This test has been failing spuriously
on the OSX bots for some time now, so ignore it as we don't currently know a
solution and it looks like it may be out of our control.
|
|
|
|
This commit is an implementation of [RFC 1184][rfc] which tweaks the behavior of
the `#![no_std]` attribute and adds a new `#![no_core]` attribute. The
`#![no_std]` attribute now injects `extern crate core` at the top of the crate
as well as the libcore prelude into all modules (in the same manner as the
standard library's prelude). The `#![no_core]` attribute disables both std and
core injection.
[rfc]: https://github.com/rust-lang/rfcs/pull/1184
|
|
After this change, the only remaining symbol we are pulling from libgcc on Win64 is `__chkstk_ms` - the stack probing routine.
|
|
|
|
This removes some of the more casual language.
The only outright goofiness I couldn't bear to remove is "these modules are the bedrock upon which all of Rust is forged, and they have mighty names like `std::slice` and `std::cmp`", which I believe the greatest sentence I have ever created.
|
|
|
|
|
|
|
|
|
|
The following APIs were all marked with a `#[stable]` tag:
* process::Child::id
* error::Error::is
* error::Error::downcast
* error::Error::downcast_ref
* error::Error::downcast_mut
* io::Error::get_ref
* io::Error::get_mut
* io::Error::into_inner
* hash::Hash::hash_slice
* hash::Hasher::write_{i,u}{8,16,32,64,size}
|
|
This fixes #26890.
To be honest, the local compile-test is still running. This just takes so long. But this looks trivial enough...
|
|
This isn't actually necessary any more with the advent of `$crate` and changes
in the compiler to expand macros to `::core::$foo` in the context of a
`#![no_std]` crate.
The libcore inner module was also trimmed down a bit to the bare bones.
|
|
|
|
|
|
- Successful merges: #26778, #27232, #27352, #27369, #27373
- Failed merges:
|
|
This isn't actually necessary any more with the advent of `$crate` and changes
in the compiler to expand macros to `::core::$foo` in the context of a
`#![no_std]` crate.
The libcore inner module was also trimmed down a bit to the bare bones.
|
|
The API we're calling requires us to pass an absolute point in time as an
argument (`pthread_cond_timedwait`) so we call `gettimeofday` ahead of time to
then add the specified duration to. Unfortuantely the current "add the duration"
logic forgot to take into account the current time's sub-second precision (e.g.
the `tv_usec` field was ignored), causing sub-second duration waits to return
spuriously.
|
|
Since most lang items are actually defined in core, these hack reexports don't actually
do anything useful.
|
|
These methods are all covered by [RFC 1158] and are currently all available on
stable Rust via the [`net2` crate][net2] on crates.io. This commit does not
touch the timeout related functions as they're still waiting on `Duration` which
is unstable anyway, so punting in favor of the `net2` crate wouldn't buy much.
[RFC 1158]: https://github.com/rust-lang/rfcs/pull/1158
[net2]: http://crates.io/crates/net2
|
|
The API we're calling requires us to pass an absolute point in time as an
argument (`pthread_cond_timedwait`) so we call `gettimeofday` ahead of time to
then add the specified duration to. Unfortuantely the current "add the duration"
logic forgot to take into account the current time's sub-second precision (e.g.
the `tv_usec` field was ignored), causing sub-second duration waits to return
spuriously.
|
|
The first paragraph of the docs of the Cursor struct ([src](https://github.com/rust-lang/rust/blob/ff6c6ce917bd6af9c5d9315708ae6be3ba0b7e91/src/libstd/io/cursor.rs#L18-L21)) contains a Markdown link. In listings (like <http://doc.rust-lang.org/nightly/std/io/>), this won't get rendered:
The hotfix would be to change the link by reference:
```rust
/// A `Cursor` wraps another type and provides it with a [`Seek`][seek]
/// implementation.
///
/// [seek]: trait.Seek.html
```
to a direct link:
```rust
/// A `Cursor` wraps another type and provides it with a
/// [`Seek`](trait.Seek.html) implementation.
```
_I have not tested this as I don't have access to a machine for compiling Rust right now._
(This seems to be a more general issue, but I think I have seen this mentioned before. This PR is just to hotfix on particular occurrence. Rustdoc seems to only read the first paragraph of a doc string for the description in index pages, and _after that_ convert Markdown to HTML.)
r? @steveklabnik
|
|
How embarassing :sob:
r? @alexcrichton
|
|
This isn't a standard header, and the other docs don't use it, so let's remove it.
|
|
This only reads five bytes, so don't use a ten byte buffer, that's confusing.
r? @alexcrichton
|
|
In spirit with https://internals.rust-lang.org/t/should-we-keep-including-obvious-imports-in-code-examples/2217, show the feature flags we're using in examples.
(also one instance of 'use')
|
|
r=alexcrichton
…ebsd 10.1 x86_64 and i686
|
|
These aren't really used for anything any more, so there doesn't seem to be much
reason to leave them around in the `rt` directory. There was some limiting of
threads spawned or tests when run under valgrind, but very little is run under
valgrind nowadays so there's also no real use keeping these around.
|
