Niko Matsakis [Tue, 3 Feb 2015 16:34:05 +0000 (11:34 -0500)]
Remove the explicit closure kind syntax from the parser and AST;
upgrade the inference based on expected type so that it is able to
infer the fn kind in isolation even if the full signature is not
available (and we could perhaps do better still in some cases, such as
extracting just the types of the arguments but not the return value).
Niko Matsakis [Tue, 3 Feb 2015 16:32:26 +0000 (11:32 -0500)]
Update compile-fail tests to use the expected type to force the
closure kind, thereby detecting what happens if there are
mismatches. Simply removing the `:` annotations caused most of these
tests to pass or produce other errors, because the inference would
convert the closure into a more appropriate kind. (The ability to
override the inference by using the expected type is an important
backdoor partly for this reason.)
Niko Matsakis [Tue, 3 Feb 2015 11:12:43 +0000 (06:12 -0500)]
Teach project to unify the return type even if a precise match is not
possible. There is some amount of duplication as a result (similar to
select) -- I am not happy about this but not sure how to fix it
without deeper rewrites.
Niko Matsakis [Mon, 2 Feb 2015 16:52:08 +0000 (11:52 -0500)]
Allow closure arguments types to unify even if we can't fully resolve
a trait obligation. Partial fix for #16440 -- closure return types are
not handled yet.
The extra check caused by the expect() call can, in general, not be
optimized away, because the length of the iterator is unknown at compile
time, causing a noticable slow-down. Since the check only triggers if
the element isn't actually found in the iterator, i.e. it isn't
guaranteed to trigger for ill-behaved ExactSizeIterators, it seems
reasonable to switch to an implementation that doesn't need the check
and just always returns None if the value isn't found.
Benchmark:
````rust
let v: Vec<u8> = (0..1024*65).map(|_| 0).collect();
b.iter(|| {
v.as_slice().iter().rposition(|&c| c == 1)
});
````
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.
projects / rust.git / log