| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This iterator was mistakenly not reexported at the top level, preventing
actually naming the type!
Closes #25519
|
|
No need for `&b"foo"[..]` to make a CString, `"foo"` will do.
|
|
The current version of the example won't compile due to unstable features.
This is an attempt to fix that, at the cost of slightly more verbose code.
|
|
This commit implements a number of standard traits for the standard library's
process I/O handles. The `FromRaw{Fd,Handle}` traits are now implemented for the
`Stdio` type and the `AsRaw{Fd,Handle}` traits are now implemented for the
`Child{Stdout,Stdin,Stderr}` types. Additionally this implements the
`AsRawHandle` trait for `Child` on Windows.
The stability markers for these implementations mention that they are stable for
1.1 as I will nominate this commit for cherry-picking to beta.
|
|
This commits adds a method to the `std::process` module to get the process
identifier of the child as a `u32`. On Windows the underlying identifier is
already a `u32`, and on Unix the type is typically defined as `c_int` (`i32` for
almost all our supported platforms), but the actually pid is normally a small
positive number.
Eventually we may add functions to load information about a process based on its
identifier or the ability to terminate a process based on its identifier, but
for now this function should enable this sort of functionality to exist outside
the standard library.
|
|
Helps prevent mixed content warnings if accessing docs over HTTPS.
Closes #25459
|
|
Just detected it while reading.
|
|
|
|
Helps prevent mixed content warnings if accessing docs over HTTPS.
Closes #25459
|
|
|
|
|
|
- Successful merges: #25354, #25381, #25391, #25395, #25397, #25398, #25401
- Failed merges:
|
|
|
|
This commit is an implementation of [RFC 1040][rfc] which is a redesign of the
currently-unstable `Duration` type. The API of the type has been scaled back to
be more conservative and it also no longer supports negative durations.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1040-duration-reform.md
The inner `duration` module of the `time` module has now been hidden (as
`Duration` is reexported) and the feature name for this type has changed from
`std_misc` to `duration`. All APIs accepting durations have also been audited to
take a more flavorful feature name instead of `std_misc`.
Closes #24874
|
|
|
|
See:
https://sourceware.org/bugzilla/show_bug.cgi?id=4887#c9
https://bugs.freedesktop.org/show_bug.cgi?id=65681
I just noticed this while talking to someone who was using
`os.environ['FOO'] = 'BAR'` in Python and since I'm learning Rust, I
was curious if it did anything special here. It looks like Rust has
an internal mutex, which helps for apps that are pure Rust, but it
will be an evil trap for someone later adding in native code (apps
like Servo and games will be at risk).
Java got this right by disallowing `setenv()` from the start.
I suggest Rust program authors only use `setenv()` early in main.
|
|
This commit is an implementation of [RFC 1040][rfc] which is a redesign of the
currently-unstable `Duration` type. The API of the type has been scaled back to
be more conservative and it also no longer supports negative durations.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1040-duration-reform.md
The inner `duration` module of the `time` module has now been hidden (as
`Duration` is reexported) and the feature name for this type has changed from
`std_misc` to `duration`. All APIs accepting durations have also been audited to
take a more flavorful feature name instead of `std_misc`.
Closes #24874
|
|
r? @nikomatsakis (note a few TODOs left in the code where I wasn't sure about stuff).
|
|
Attempted to organize them in a way more relevant to what newbies
would be interested in hearing.
I am not satisfied by this at all, but by virtue of deleting old links alone I think it is an improvement.
r? @steveklabnik
|
|
|
|
|
|
Conflicts:
mk/platform.mk
src/librustc/session/config.rs
src/librustc_back/target/aarch64_apple_ios.rs
src/librustc_back/target/aarch64_linux_android.rs
src/librustc_back/target/arm_linux_androideabi.rs
src/librustc_back/target/arm_unknown_linux_gnueabi.rs
src/librustc_back/target/arm_unknown_linux_gnueabihf.rs
src/librustc_back/target/armv7_apple_ios.rs
src/librustc_back/target/armv7s_apple_ios.rs
src/librustc_back/target/i386_apple_ios.rs
src/librustc_back/target/i686_apple_darwin.rs
src/librustc_back/target/i686_pc_windows_gnu.rs
src/librustc_back/target/i686_unknown_dragonfly.rs
src/librustc_back/target/i686_unknown_linux_gnu.rs
src/librustc_back/target/mips_unknown_linux_gnu.rs
src/librustc_back/target/mipsel_unknown_linux_gnu.rs
src/librustc_back/target/mod.rs
src/librustc_back/target/powerpc_unknown_linux_gnu.rs
src/librustc_back/target/x86_64_apple_darwin.rs
src/librustc_back/target/x86_64_apple_ios.rs
src/librustc_back/target/x86_64_pc_windows_gnu.rs
src/librustc_back/target/x86_64_unknown_dragonfly.rs
src/librustc_back/target/x86_64_unknown_freebsd.rs
src/librustc_back/target/x86_64_unknown_linux_gnu.rs
src/librustc_back/target/x86_64_unknown_openbsd.rs
src/librustc_llvm/lib.rs
src/librustc_trans/back/link.rs
src/librustc_trans/trans/base.rs
src/libstd/os.rs
src/rustllvm/RustWrapper.cpp
|
|
|
|
Change from "must be used with behind a pointer" to "must be used behind a pointer"
|
|
Several Minor API / Reference Documentation Fixes
- Fix a few small errors in the reference.
- Fix paper cuts in the API docs.
Fixes #24882
Fixes #25233
Fixes #25250
|
|
|
|
Fixes #25233
|
|
Fixes #24882
|
|
Add example for HashMap::entry()
|
|
|
|
Change from "must be used with behind a pointer" to "must be used behind a pointer"
|
|
In my opinion this looks nicer, but also it matches the whitespace generally
used for stability markers more closely.
|
|
I've found that there are still huge amounts of occurrences of `task`s in the documentation. This PR tries to eliminate all of them in favor of `thread`.
|
|
|
|
dropck: must assume `Box<Trait + 'a>` has a destructor of interest.
Fix #25199.
This detail was documented in [RFC 769]; the implementation was just missing.
[breaking-change]
The breakage here falls into both obvious and non-obvious cases.
The obvious case: if you were relying on the unsoundness this exposes (namely being able to reference dead storage from a destructor, by doing it via a boxed trait object bounded by the lifetime of the dead storage), then this change disallows that.
The non-obvious cases: The way dropck works, it causes lifetimes to be extended to longer extents than they covered before. I.e. lifetimes that are attached as trait-bounds may become longer than they were previously.
* This includes lifetimes that are only *implicitly* attached as trait-bounds (due to [RFC 599]). So you may have code that was e.g. taking a parameter of type `&'a Box<Trait>` (which expands to `&'a Box<Trait+'a>`), that now may need to be assigned type `&'a Box<Trait+'static>` to ensure that `'a` is not inadvertantly inferred to a region that is actually too long. (See commit ee06263 for an example of this.)
[RFC 769]: https://github.com/rust-lang/rfcs/blob/master/text/0769-sound-generic-drop.md#the-drop-check-rule
[RFC 599]: https://github.com/rust-lang/rfcs/blob/master/text/0599-default-object-bound.md
|
|
Attempted to organize them in a way more relevant to what newbies
would be interested in hearing.
|
|
- Successful merges: #24864, #25140, #25179, #25181, #25190, #25194, #25195, #25198, #25203, #25210, #25211, #25215
- Failed merges: #25200
|
|
Building with `--target=mipsel-unknown-linux-gnu` currently results in the following errors, fixed by this PR:
```
rustc: x86_64-unknown-linux-gnu/stage2/lib/rustlib/mipsel-unknown-linux-gnu/lib/libstd
/vol/rust/src/libstd/os/linux/raw.rs:76:21: 76:28 error: use of undeclared type name `c_ulong`
/vol/rust/src/libstd/os/linux/raw.rs:76 pub st_dev: c_ulong,
^~~~~~~
/vol/rust/src/libstd/os/linux/raw.rs:83:22: 83:29 error: use of undeclared type name `c_ulong`
/vol/rust/src/libstd/os/linux/raw.rs:83 pub st_rdev: c_ulong,
^~~~~~~
/vol/rust/src/libstd/sys/common/net2.rs:210:52: 210:70 error: unresolved name `libc::TCP_KEEPIDLE`
/vol/rust/src/libstd/sys/common/net2.rs:210 setsockopt(&self.inner, libc::IPPROTO_TCP, libc::TCP_KEEPIDLE,
```
|
|
This commit is an implementation of [RFC 1066][rfc] where the conclusion was
that leaking a value is a safe operation in Rust code, so updating the signature
of this function follows suit.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1066-safe-mem-forget.md
Closes #25186
|
|
An automated script was run against the `.rs` and `.md` files,
subsituting every occurrence of `task` with `thread`. In the `.rs`
files, only the texts in the comment blocks were affected.
|
|
There are two interesting kinds of breakage illustrated here:
1. `Box<Trait>` in many contexts is treated as `Box<Trait + 'static>`,
due to [RFC 599]. However, in a type like `&'a Box<Trait>`, the
`Box<Trait>` type will be expanded to `Box<Trait + 'a>`, again due
to [RFC 599]. This, combined with the fix to Issue 25199, leads to
a borrowck problem due the combination of this function signature
(in src/libstd/net/parser.rs):
```rust
fn read_or<T>(&mut self, parsers: &mut [Box<FnMut(&mut Parser) -> Option<T>>]) -> Option<T>;
```
with this call site (again in src/libstd/net/parser.rs):
```rust
fn read_ip_addr(&mut self) -> Option<IpAddr> {
let ipv4_addr = |p: &mut Parser| p.read_ipv4_addr().map(|v4| IpAddr::V4(v4));
let ipv6_addr = |p: &mut Parser| p.read_ipv6_addr().map(|v6| IpAddr::V6(v6));
self.read_or(&mut [Box::new(ipv4_addr), Box::new(ipv6_addr)])
}
```
yielding borrowck errors like:
```
parser.rs:265:27: 265:69 error: borrowed value does not live long enough
parser.rs:265 self.read_or(&mut [Box::new(ipv4_addr), Box::new(ipv6_addr)])
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
(full log at: https://gist.github.com/pnkfelix/e2e80f1a71580f5d3103 )
The issue here is perhaps subtle: the `parsers` argument is
inferred to be taking a slice of boxed objects with the implicit
lifetime bound attached to the `self` parameter to `read_or`.
Meanwhile, the fix to Issue 25199 (added in a forth-coming commit)
is forcing us to assume that each boxed object may have a
destructor that could refer to state of that lifetime, and
*therefore* that inferred lifetime is required to outlive the boxed
object itself.
In this case, the relevant boxed object here is not going to make
any such references; I believe it is just an artifact of how the
expression was built that it is not assigned type:
`Box<FnMut(&mut Parser) -> Option<T> + 'static>`.
(i.e., mucking with the expression is probably one way to fix this
problem).
But the other way to fix it, adopted here, is to change the
`read_or` method type to force make the (presumably-intended)
`'static` bound explicit on the boxed `FnMut` object.
(Note: this is still just the *first* example of breakage.)
2. In `macro_rules.rs`, the `TTMacroExpander` trait defines a method
with signature:
```rust
fn expand<'cx>(&self, cx: &'cx mut ExtCtxt, ...) -> Box<MacResult+'cx>;
```
taking a `&'cx mut ExtCtxt` as an argument and returning a
`Box<MacResult'cx>`.
The fix to Issue 25199 (added in aforementioned forth-coming
commit) assumes that a value of type `Box<MacResult+'cx>` may, in
its destructor, refer to a reference of lifetime `'cx`; thus the
`'cx` lifetime is forced to outlive the returned value.
Meanwhile, within `expand.rs`, the old code was doing:
```rust
match expander.expand(fld.cx, ...).make_pat() { ... => immutable borrow of fld.cx ... }
```
The problem is that the `'cx` lifetime, inferred for the
`expander.expand` call, has now been extended so that it has to
outlive the temporary R-value returned by `expanded.expand`. But
call is also reborrowing `fld.cx` *mutably*, which means that this
reborrow must end before any immutable borrow of `fld.cx`; but
there is one of those within the match body. (Note that the
temporary R-values for the input expression to `match` all live as
long as the whole `match` expression itself (see Issue #3511 and PR
#11585).
To address this, I moved the construction of the pat value into its
own `let`-statement, so that the `Box<MacResult>` will only live
for as long as the initializing expression for the `let`-statement,
and thus allow the subsequent immutable borrow within the `match`.
[RFC 599]: https://github.com/rust-lang/rfcs/blob/master/text/0599-default-object-bound.md
|
|
This commit is an implementation of [RFC 1066][rfc] where the conclusion was
that leaking a value is a safe operation in Rust code, so updating the signature
of this function follows suit.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1066-safe-mem-forget.md
Closes #25186
|
|
Perform unsafe initialization up front and then only afterward the mutex is in
place do we initialize it.
|
|
This module has been removed for quite some time!
|
|
Now that `std::old_io` has been removed for quite some time the naming real
estate here has opened up to allow these modules to move back to their proper
names.
|
|
|
|
So, I realize this is really late in the game so it's unlikely to be accepted but `FromRawFd`/`FromRawHandle` are necessary for fine grain control over file creation. For example, the current `OpenOptions` does not provide a way to avoid file creation races (there's no way to specify `O_EXCL` or the windows equivalent). Stabilizing these traits and their implementations will give 1.0 users fine-grain control over file creation without committing to any new complex APIs. Additionally, `AsRawFd`/`AsRawHandle` are already stable so I feel that that stabilizing their inverses is a reasonably small change.
Disclaimer: I'm asking because my crate, tempfile, depends on this feature.
|
|
The [UnsafeCell documentation says it is undefined behavior](http://doc.rust-lang.org/nightly/std/cell/struct.UnsafeCell.html), so people shouldn't do it.
This happened to catch one case in libstd that was doing this, and I switched that to use an UnsafeCell internally.
Closes #13146
|
|
Previously, `try_write` actually only obtained shared read access (but would return a `RwLockWriteGuard` if that access was successful).
Also updates the docs for `try_read` and `try_write`, which were leftover from when those methods returned `Option` instead of `Result`.
|
|
|
