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.
Using rust 1.0.0 (a59de37e9).
It might be obvious, but I'm not well versed with rust, so feedback is very welcome.
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#c9https://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
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
Several Minor API / Reference Documentation Fixes
- Fix a few small errors in the reference.
- Fix paper cuts in the API docs.
Fixes#24882Fixes#25233Fixes#25250
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
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,
```
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
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`.
Many bounds are currently of the form `T: ?Sized + AsRef<OsStr>` where the
argument is `&T`, but the pattern elsewhere (primarily `std::fs`) has been to
remove the `?Sized` bound and take `T` instead (allowing usage with both
references and owned values). This commit generalizes the possible apis in
`std::env` from `&T` to `T` in this fashion.
The `split_paths` function remains the same as the return value borrows the
input value, so ta borrowed reference is required.
