I'd really like to be able to do something like
```rust
struct MapChain<'next, K, V> {
info: BlockInfo,
map: HashMap<K, V>,
next: Option<&'next mut MapChain<'next, K, V>
}
```
but I can't get the lifetimes to work out.
I'd really like to be able to do something like
struct MapChain<'next, K, V> {
info: BlockInfo,
map: HashMap<K, V>,
next: Option<&'next mut MapChain<'next, K, V>
}
but I can't get the lifetimes to work out.
Note that this removes a number of run-pass tests which are exercising behavior
of the old runtime. This functionality no longer exists and is thoroughly tested
inside of libgreen and libnative. There isn't really the notion of "starting the
runtime" any more. The major notion now is "bootstrapping the initial task".
This extracts everything related to green scheduling from libstd and introduces
a new libgreen crate. This mostly involves deleting most of std::rt and moving
it to libgreen.
Along with the movement of code, this commit rearchitects many functions in the
scheduler in order to adapt to the fact that Local::take now *only* works on a
Task, not a scheduler. This mostly just involved threading the current green
task through in a few locations, but there were one or two spots where things
got hairy.
There are a few repercussions of this commit:
* tube/rc have been removed (the runtime implementation of rc)
* There is no longer a "single threaded" spawning mode for tasks. This is now
encompassed by 1:1 scheduling + communication. Convenience methods have been
introduced that are specific to libgreen to assist in the spawning of pools of
schedulers.
using the expansion info.
Previously something like
struct NotEq;
#[deriving(Eq)]
struct Error {
foo: NotEq
}
would just point to the `foo` field, with no mention of the
`deriving(Eq)`. With this patch, the compiler creates a note saying "in
expansion of #[deriving(Eq)]" pointing to the Eq.
This reverts commit c54427ddfb.
Leave the #[ignores] in that were added to rustpkg tests.
Conflicts:
src/librustc/driver/driver.rs
src/librustc/metadata/creader.rs
ToStr, Encodable and Decodable are not marked as such, since they're
already expensive, and lead to large methods, so inlining will bloat the
metadata & the binaries.
This means that something like
#[deriving(Eq)]
struct A { x: int }
creates an instance like
#[doc = "Automatically derived."]
impl ::std::cmp::Eq for A {
#[inline]
fn eq(&self, __arg_0: &A) -> ::bool {
match *__arg_0 {
A{x: ref __self_1_0} =>
match *self {
A{x: ref __self_0_0} => true && __self_0_0.eq(__self_1_0)
}
}
}
#[inline]
fn ne(&self, __arg_0: &A) -> ::bool {
match *__arg_0 {
A{x: ref __self_1_0} =>
match *self {
A{x: ref __self_0_0} => false || __self_0_0.ne(__self_1_0)
}
}
}
}
(The change being the `#[inline]` attributes.)
These two attributes are no longer useful now that Rust has decided to leave
segmented stacks behind. It is assumed that the rust task's stack is always
large enough to make an FFI call (due to the stack being very large).
There's always the case of stack overflow, however, to consider. This does not
change the behavior of stack overflow in Rust. This is still normally triggered
by the __morestack function and aborts the whole process.
C stack overflow will continue to corrupt the stack, however (as it did before
this commit as well). The future improvement of a guard page at the end of every
rust stack is still unimplemented and is intended to be the mechanism through
which we attempt to detect C stack overflow.
Closes#8822Closes#10155
This rearranges the deriving code so that #[deriving] a trait on a field
that doesn't implement that trait will point to the field in question,
e.g.
struct NotEq; // doesn't implement Eq
#[deriving(Eq)]
struct Foo {
ok: int,
also_ok: ~str,
bad: NotEq // error points here.
}
Unfortunately, this means the error is disconnected from the `deriving`
itself but there's no current way to pass that information through to
rustc except via the spans, at the moment.
Fixes#7724.
