Alex Crichton [Tue, 3 Feb 2015 23:35:54 +0000 (15:35 -0800)]
rollup merge of #21835: alexcrichton/iov2
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.
Alex Crichton [Tue, 3 Feb 2015 23:35:53 +0000 (15:35 -0800)]
rollup merge of #21759: aturon/new-path
This PR implements [path reform](https://github.com/rust-lang/rfcs/pull/474), and motivation and details for the change can be found there.
For convenience, the old path API is being kept as `old_path` for the time being. Updating after this PR is just a matter of changing imports to `old_path` (which is likely not needed, since the prelude entries still export the old path API).
This initial PR does not include additional normalization or platform-specific path extensions. These will be done in follow up commits or PRs.
Aaron Turon [Thu, 29 Jan 2015 22:03:36 +0000 (14:03 -0800)]
Rename std::path to std::old_path
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.
Alex Crichton [Sun, 1 Feb 2015 04:24:36 +0000 (20:24 -0800)]
std: Add `io` module again
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.
bors [Tue, 3 Feb 2015 12:49:21 +0000 (12:49 +0000)]
Auto merge of #21675 - huonw:less-false-positives, r=nikomatsakis
That is, when offering suggestions for unresolved method calls, avoid
suggesting traits for which implementing the trait for the receiver type
either makes little sense (e.g. type errors, or sugared unboxed
closures), or violates coherence.
The latter is approximated by ensuring that at least one of `{receiver
type, trait}` is local. This isn't precisely correct due to
multidispatch, but the error messages one encounters in such situation
are useless more often than not; it is better to be conservative and
miss some cases, than have overly many false positives (e.g. writing
`some_slice.map(|x| ...)` uselessly suggested that one should implement
`IteratorExt` for `&[T]`, while the correct fix is to call `.iter()`).
Huon Wilson [Tue, 27 Jan 2015 00:29:30 +0000 (11:29 +1100)]
Try to only suggest implementable traits for method calls.
That is, when offering suggestions for unresolved method calls, avoid
suggesting traits for which implementing the trait for the receiver type
either makes little sense (e.g. type errors, or sugared unboxed
closures), or violates coherence.
The latter is approximated by ensuring that at least one of `{receiver
type, trait}` is local. This isn't precisely correct due to
multidispatch, but the error messages one encounters in such situation
are useless more often than not; it is better to be conservative and
miss some cases, than have overly many false positives (e.g. writing
`some_slice.map(|x| ...)` uselessly suggested that one should implement
`IteratorExt` for `&[T]`, while the correct fix is to call `.iter()`).
bors [Tue, 3 Feb 2015 10:40:33 +0000 (10:40 +0000)]
Auto merge of #21745 - chris-morgan:add-missing-unstable-attributes, r=huonw
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.
Alex Crichton [Mon, 2 Feb 2015 19:01:23 +0000 (11:01 -0800)]
rollup merge of #21854: alexcrichton/try-borrow
The existence of these two functions is at odds with our current [error
conventions][conventions] which recommend that panicking and `Result`-like
variants should not be provided together.
This commit adds a new `borrow_state` function returning a `BorrowState` enum to
`RefCell` which serves as a replacemnt for the `try_borrow` and `try_borrow_mut`
functions.
Alex Crichton [Mon, 2 Feb 2015 19:01:19 +0000 (11:01 -0800)]
rollup merge of #21849: alexcrichton/warn2note
There [have been reports][issue] of an unconditional warning causing tooling to
go awry. This isn't actually a warning per se, it's more of a note anyway!
Alex Crichton [Mon, 2 Feb 2015 19:01:16 +0000 (11:01 -0800)]
rollup merge of #21842: alexcrichton/issue-21839
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.
Alex Crichton [Mon, 2 Feb 2015 19:01:15 +0000 (11:01 -0800)]
rollup merge of #21832: genbattle/doc-unicode-escapes
Unicode escapes were changed in [this RFC](https://github.com/rust-lang/rfcs/blob/28aeb3c391c9afd344f124d3a69bdc2a420638b2/text/0446-es6-unicode-escapes.md) to use the ES6 \u{00FFFF} syntax with a variable number of digits from 1-6, eliminating the need for two different syntaxes for unicode literals.
I have updated The Reference and grammar.md to reflect these changes.
Alex Crichton [Mon, 2 Feb 2015 18:58:10 +0000 (10:58 -0800)]
rollup merge of #21817: edwardw/symmetric-binop
For "symmetric" binary operators, meaning the types of two sides must be
equal, if the type of LHS doesn't know yet but RHS does, use that as an
hint to infer LHS' type.
Alex Crichton [Mon, 2 Feb 2015 18:58:04 +0000 (10:58 -0800)]
rollup merge of #21794: alexcrichton/stabilize-atomic-usize
These methods were intended to be stable as of #16258 but the tags have since
been lost in various refactorings. This commit re-adds the `#[stable]`
attributes to each of these functions.
Alex Crichton [Mon, 2 Feb 2015 18:56:59 +0000 (10:56 -0800)]
rollup merge of #21782: alexcrichton/issue-21771
Previously if --extern was specified it would not override crates in the
standard distribution, leading to issues like #21771. This commit alters the
behavior such that if --extern is passed then it will always override any other
choice of crates and no previous match will be used (unless it is the same path
as --extern).
Alex Crichton [Mon, 2 Feb 2015 18:56:57 +0000 (10:56 -0800)]
rollup merge of #21754: semarie/openbsd-rebased
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.
The existence of these two functions is at odds with our current [error
conventions][conventions] which recommend that panicking and `Result`-like
variants should not be provided together.
This commit adds a new `borrow_state` function returning a `BorrowState` enum to
`RefCell` which serves as a replacemnt for the `try_borrow` and `try_borrow_mut`
functions.
Alex Crichton [Sun, 1 Feb 2015 22:25:55 +0000 (14:25 -0800)]
rustc: Change an unconditional `warn` to a `note`
There [have been reports][issue] of an unconditional warning causing tooling to
go awry. This isn't actually a warning per se, it's more of a note anyway!
bors [Sun, 1 Feb 2015 21:53:53 +0000 (21:53 +0000)]
Auto merge of #21318 - stepancheg:box-fns, r=alexcrichton
Functions are needed for safety and convenience.
It is a common pattern to use `mem::transmute` to convert between
`Box` and raw pointer, like this:
```
let b = Box::new(3);
let p = mem::transmute(b);
// pass `p` to some C library
```
After this commit, conversion can be written as:
```
let p = b.into_raw();
```
`into_raw` and `from_raw` functions are still unsafe, but they are
much safer than `mem::transmute`, because *raw functions do not
convert between incompatible pointers. For example, this likely
incorrect code can be successfully compiled:
```
let p: *mut u64 = ...
let b: Box<u32> = mem::transmute(p);
```
Using `from_raw` results in compile-time error:
```
let p: *mut u64 = ...
let b: Box<u32> = Box::from_raw(p); // compile-time error
```
`into_raw` and `from_raw` functions are similar to C++ `std::unique_ptr`
`release` function [1] and constructor from pointer [2].
Alex Crichton [Sun, 1 Feb 2015 20:15:36 +0000 (12:15 -0800)]
std: Remove extra type params on iter adaptors
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.
Alex Crichton [Tue, 27 Jan 2015 20:20:58 +0000 (12:20 -0800)]
std: Add a new `env` module
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:
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:
bors [Sun, 1 Feb 2015 19:07:11 +0000 (19:07 +0000)]
Auto merge of #21806 - edwardw:new-range-impl, r=alexcrichton
The new `::ops::Range` has separated implementations for each of the
numeric types, while the old `::iter::Range` has one for type `Int`.
However, we do not take output bindings into account when selecting
traits. So it confuses `typeck` and makes the new range does not work as
good as the old one when it comes to type inference.
This patch implements `Iterator` for the new range for one type `Int`.
This limitation could be lifted, however, if we ever reconsider the
output types' role in type inference.
Stepan Koltsov [Sun, 1 Feb 2015 17:15:44 +0000 (20:15 +0300)]
box: into_raw, from_raw functions
Functions are needed for safety and convenience.
It is a common pattern to use `mem::transmute` to convert between
`Box` and raw pointer, like this:
```
let b = Box::new(3);
let p = mem::transmute(b);
// pass `p` to some C library
```
After this commit, conversion can be written as:
```
let p = boxed::into_raw(b);
```
`into_raw` and `from_raw` functions are still unsafe, but they are
much safer than `mem::transmute`, because *raw functions do not
convert between incompatible pointers. For example, this likely
incorrect code can be successfully compiled:
```
let p: *mut u64 = ...
let b: Box<u32> = mem::transmute(p);
```
Using `from_raw` results in compile-time error:
```
let p: *mut u64 = ...
let b: Box<u32> = Box::from_raw(p); // compile-time error
```
`into_raw` and `from_raw` functions are similar to C++ `std::unique_ptr`
`release` function [1] and constructor from pointer [2].
Sébastien Marie [Fri, 30 Jan 2015 13:28:13 +0000 (14:28 +0100)]
openbsd: remove specific block and cleanup linkage
- 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)
Sébastien Marie [Fri, 30 Jan 2015 07:15:28 +0000 (08:15 +0100)]
openbsd: incoporate remarks
- 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
bors [Sun, 1 Feb 2015 13:01:57 +0000 (13:01 +0000)]
Auto merge of #21805 - nikomatsakis:closure-inference-refactor-1, r=eddyb
Currently, we only infer the kind of a closure based on the expected type or explicit annotation. If neither applies, we currently report an error. This pull request changes that case to defer the decision until we are able to analyze the actions of the closure: closures which mutate their environment require `FnMut`, closures which move out of their environment require `FnOnce`.
This PR is not the end of the story:
- It does not remove the explicit annotations nor disregard them. The latter is the logical next step to removing them (we'll need a snapshot before we can do anything anyhow). Disregarding explicit annotations might expose more bugs since right now all closures in libstd/rustc use explicit annotations or the expected type, so this inference never kicks in.
- The interaction with instantiating type parameter fallbacks leaves something to be desired. This is mostly just saying that the algorithm from https://github.com/rust-lang/rfcs/pull/213 needs to be implemented, which is a separate bug. There are some semi-subtle interactions though because not knowing whether a closure is `Fn` vs `FnMut` prevents us from resolving obligations like `F : FnMut(...)`, which can in turn prevent unification of some type parameters, which might (in turn) lead to undesired fallback. We can improve this situation however -- even if we don't know whether (or just how) `F : FnMut(..)` holds or not for some closure type `F`, we can still perform unification since we *do* know the argument and return types. Once kind inference is done, we can complete the `F : FnMut(..)` analysis -- which might yield an error if (e.g.) the `F` moves out of its environment.
Niko Matsakis [Sat, 31 Jan 2015 11:29:04 +0000 (06:29 -0500)]
To handle more complex cases, modify the deferred call handler to be
specialized to closures, and invoke them as soon as we know the
closure kind. I thought initially we would need a fixed-point
inference algorithm but it appears I was mistaken, so we can do this.
Niko Matsakis [Sat, 31 Jan 2015 11:33:41 +0000 (06:33 -0500)]
Adjust the handling of trait obligations and defaults to account for
upvar inference. Upvar inference can cause some obligations to be
deferred, notably things like `F : Sized` where `F` is a closure type,
or `F : FnMut`. Adjust the ordering therefore so that we process all
traits and apply fallback, do upvar inference, and only then start
reporting errors for outstanding obligations.
Niko Matsakis [Sat, 24 Jan 2015 22:32:10 +0000 (17:32 -0500)]
Introduce the notion of deferred resolutions and use it to hold off on
doing the final checking for closure calls until after trait inference
is performed. This isn't important now, but it's essential if we are to
delay inferring the closure kind.
Edward Wang [Sat, 31 Jan 2015 14:19:13 +0000 (22:19 +0800)]
Make sure type inference with `a..b` as good as `range(a,b)`
The new `::ops::Range` has separated implementations for each of the
numeric types, while the old `::iter::Range` has one for type `Int`.
However, we do not take output bindings into account when selecting
traits. So it confuses `typeck` and makes the new range does not work as
good as the old one when it comes to type inference.
This patch implements `Iterator` for the new range for one type `Int`.
This limitation could be lifted, however, if we ever reconsider the
output types' role in type inference.
Nick Sarten [Sun, 1 Feb 2015 03:42:22 +0000 (16:42 +1300)]
Updated unicode escape documentation to match current implementation.
Unicode escapes were changed in [this
RFC](https://github.com/rust-lang/rfcs/blob/28aeb3c391c9afd344f124d3a69bdc2a420638b2/text/0446-es6-unicode-escapes.md)
to use the ES6 \u{00FFFF} syntax with a variable number of digits from
1-6, eliminating the need for two different syntaxes for unicode
literals.
bors [Sun, 1 Feb 2015 01:34:08 +0000 (01:34 +0000)]
Auto merge of #21792 - nikomatsakis:orphan-ordered-first, r=aturon
Update the coherence rules to "covered first" -- the first type parameter to contain either a local type or a type parameter must contain only covered type parameters.
projects / rust.git / log