fn main()
{
let mut guards = vec![make_thread(3)];
for i in 4i64..16
{
guards.push(make_thread(i));
}
}
```
GDB output on my machine:
```
(gdb) info threads
Id Target Id Frame
15 Thread 0x7fdfbb35f700 (LWP 23575) "MyThread3" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
14 Thread 0x7fdfba7ff700 (LWP 23576) "MyThread4" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
13 Thread 0x7fdfba5fe700 (LWP 23577) "MyThread5" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
12 Thread 0x7fdfba3fd700 (LWP 23578) "MyThread6" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
11 Thread 0x7fdfb8dfe700 (LWP 23580) "MyThread4" 0x00007fdfbb746193 in select () from /usr/lib/libc.so.6
10 Thread 0x7fdfb8fff700 (LWP 23579) "MyThread7" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
9 Thread 0x7fdfb8bfd700 (LWP 23581) "MyThread8" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
8 Thread 0x7fdfb3fff700 (LWP 23582) "MyThread9" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
7 Thread 0x7fdfb3dfe700 (LWP 23583) "MyThread10" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
6 Thread 0x7fdfb3bfd700 (LWP 23584) "MyThread11" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
5 Thread 0x7fdfb2bff700 (LWP 23585) "MyThread12" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
4 Thread 0x7fdfb29fe700 (LWP 23586) "MyThread13" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
3 Thread 0x7fdfb27fd700 (LWP 23587) "MyThread14" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
2 Thread 0x7fdfb1bff700 (LWP 23588) "MyThread15" 0x00007fdfbbe35a8d in nanosleep () from /usr/lib/libpthread.so.0
* 1 Thread 0x7fdfbc411800 (LWP 23574) "threads" 0x00007fdfbbe2e505 in pthread_join () from /usr/lib/libpthread.so.0
```
(I'm not sure why one of the threads is duplicated, but it does that without my patch too...)
Alex Crichton [Fri, 30 Jan 2015 20:02:51 +0000 (12:02 -0800)]
rollup merge of #21495: richo/unexported-unmangled-lint
The usecase is that functions made visible to systems outside of the
rust ecosystem require the symbol to be visible.
This adds a lint for functions that are not exported, but also not mangled.
It has some gotchas:
[ ]: There is fallout in core that needs taking care of
[ ]: I'm not convinced the error message is correct
[ ]: It has no tests
~~However, there's an underlying issue which I'd like feedback on- which is that my belief that that non-pub functions would not have their symbols exported, however that seems not to be the case in the first case that this lint turned up in rustc (`rust_fail`), which intuition suggests has been working.~~
This seems to be a separate bug in rust, wherein the symbols are exported in binaries, but not in rlibs or dylibs. This lint would catch that case.
// iterate over immutable references
for x in &v {
assert_eq!(x, &1);
}
// iterate over mutable references
for x in &mut v {
assert_eq!(x, &mut 1);
}
// iterate over values, this consumes `v`
for x in v {
assert_eq!(x, 1);
}
```
[breaking-change]s
For loops now "consume" (move) the iterator, this breaks iterating over mutable references to iterators, and also breaks multiple iterations over the same iterator:
``` rust
fn foo(mut it: &mut Iter) { // `Iter` implements `Iterator`
for x in it { .. } //~ error: `&mut Iter` doesn't implement Iterator
}
fn bar() {
for x in it { .. } //~ note: `it` moved here
for x in it { .. } //~ error: `it` has been moved
}
```
Both cases can be fixed using the `by_ref()` adapter to create an iterator from the mutable reference:
``` rust
fn foo(mut it: &mut Iter) {
for x in it.by_ref() { .. }
}
fn bar() {
for x in it.by_ref() { .. }
for x in it { .. }
}
```
This PR also makes iterator non-implicitly copyable, as this was source of subtle bugs in the libraries. You can still use `clone()` to explictly copy the iterator.
Finally, since the for loops are implemented in the frontend and use global paths to `IntoIterator`, `Iterator` and `Option` variants, users of the `core` crate will have to use add an `std` module to the root of their crate to be able to use for loops:
``` rust
#![no_std]
extern crate core;
fn main() {
for x in 0..10 {}
}
#[doc(hidden)]
mod std {
// these imports are needed to use for-loops
pub use core::iter;
pub use core::option;
}
```
bors [Fri, 30 Jan 2015 07:57:14 +0000 (07:57 +0000)]
Auto merge of #21351 - eddyb:x-coerce--a-new-hope, r=nikomatsakis
Coercions will now attempt to autoderef as needed before reborrowing.
This includes overloaded `Deref`, e.g. `&Rc<T>` coerces to `&T`, and
`DerefMut`, e.g. `&mut Vec<T>` coerces to `&mut [T]` (in addition to `&[T]`).
Closes #21432.
bors [Thu, 29 Jan 2015 22:54:19 +0000 (22:54 +0000)]
Auto merge of #21692 - pnkfelix:fsk-fix-coerce-match-20055, r=eddyb
trans: When coercing to `Box<Trait>` or `Box<[T]>`, leave datum in it's original L-/R-value state.
This fixes a subtle issue where temporaries were being allocated (but not necessarily initialized) to the (parent) terminating scope of a match expression; in particular, the code to zero out the temporary emitted by `datum.store_to` is only attached to the particular match-arm for that temporary, but when going down other arms of the match expression, the temporary may falsely appear to have been initialized, depending on what the stack held at that location, and thus may have its destructor erroneously run at the end of the terminating scope.
FIx #20055.
(There may be a latent bug still remaining in `fn into_fat_ptr`, but I am so annoyed by the test/run-pass/coerce_match.rs failures that I want to land this now.)
bors [Thu, 29 Jan 2015 19:36:03 +0000 (19:36 +0000)]
Auto merge of #21691 - edwardw:double-closure, r=nikomatsakis
It was considered to be impossible but actually it can
happen for nested closures. Also, because there must
be nested closures when this happens, we can use more
targeted help message.
Niko Matsakis [Mon, 12 Jan 2015 15:27:25 +0000 (10:27 -0500)]
Update test files; mostly the problem is that they were using the
explicit form `Fn<A,B>` and now should use `Fn(A) -> B` or
`Fn<A,Output=B>`, but in some cases we get duplicate error
reports. This is mildly annoying and arises because of the main error
and another error from the projection. Might be worth squashing those,
but seems like a separate problem.
Niko Matsakis [Sat, 10 Jan 2015 16:54:15 +0000 (11:54 -0500)]
Move return type an associated type of the `Fn*` traits. Mostly this involves tweaking things in
the compiler that assumed two input types to assume two ouputs; we also have to teach `project.rs`
to project `Output` from the unboxed closure and fn traits.
Niko Matsakis [Mon, 26 Jan 2015 19:20:38 +0000 (14:20 -0500)]
Add the notion of normalizing a parameter environment and ensure that
all parameter environments are normalized. Correspondingly, stop
normalizing predicates we extract out of the environment. Fixes #21664.
bors [Wed, 28 Jan 2015 03:59:14 +0000 (03:59 +0000)]
Auto merge of #21248 - brson:feature-staging, r=alexcrichton
This implements the remaining bits of 'feature staging', as described in [RFC 507](https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md).
This is not quite done, but the substance of the work is complete so submitting for early review.
Key changes:
* `unstable`, `stable` and `deprecated` attributes all require 'feature' and 'since', and support an optional 'reason'.
* The `unstable` lint is removed.
* A new 'stability checking' pass warns when a used unstable library feature has not been activated with the `feature` attribute. At 1.0 beta this will become an error.
* A new 'unused feature checking' pass emits a lint ('unused_feature', renamed from 'unknown_feature') for any features that were activated but not used.
* A new tidy script `featureck.py` performs some global sanity checking, particularly that 'since' numbers agree, and also prints out a summary of features.
Differences from RFC:
* As implemented `unstable` requires a `since` attribute. I do not know if this is useful. I included it in the original sed script and just left it.
* RFC didn't specify the name of the optional 'reason' attribute.
* This continues to use 'unstable', 'stable' and 'deprecated' names (the 'nice' names) instead of 'staged_unstable', but only activates them with the crate-level 'staged_api' attribute.
I intend to update the RFC based on the outcome of this PR.
Issues:
* The unused feature check doesn't account for language features - i.e. you can activate a language feature, not use it, and not get the error.
Open questions:
* All unstable and deprecated features are named 'unnamed_feature', which i picked just because it is uniquely greppable. This is the 'catch-all' feature. What should it be?
* All stable features are named 'grandfathered'. What should this be?
TODO:
* Add check that all `deprecated` attributes are paired with a `stable` attribute in order to preserve the knowledge about when a feature became stable.
* Update rustdoc in various ways.
* Remove obsolete stability discussion from reference.
* Add features for 'path', 'io', 'os', 'hash' and 'rand'.