rust/src/test/run-fail/task-spawn-barefn.rs, branch 1.25.0

Adding ignore-emscripten to failing tests.

2016-09-30T21:02:44+00:00

Fix the tests broken by replacing `task` with `thread`

2015-05-08T19:04:08+00:00

Squeeze the last bits of `task`s in documentation in favor of `thread`

2015-05-08T17:24:18+00:00

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.

Fallout from stabilization

2015-02-17T23:14:17+00:00

Fallout from stabilization

2015-01-06T22:57:52+00:00

Remove deprecated functionality

2015-01-04T07:43:57+00:00

This removes a large array of deprecated functionality, regardless of how recently it was deprecated. The purpose of this commit is to clean out the standard libraries and compiler for the upcoming alpha release. Some notable compiler changes were to enable warnings for all now-deprecated command line arguments (previously the deprecated versions were silently accepted) as well as removing deriving(Zero) entirely (the trait was removed). The distribution no longer contains the libtime or libregex_macros crates. Both of these have been deprecated for some time and are available externally.

Rename fail! to panic!

2014-10-29T15:43:07+00:00

https://github.com/rust-lang/rfcs/pull/221 The current terminology of "task failure" often causes problems when writing or speaking about code. You often want to talk about the possibility of an operation that returns a Result "failing", but cannot because of the ambiguity with task failure. Instead, you have to speak of "the failing case" or "when the operation does not succeed" or other circumlocutions. Likewise, we use a "Failure" header in rustdoc to describe when operations may fail the task, but it would often be helpful to separate out a section describing the "Err-producing" case. We have been steadily moving away from task failure and toward Result as an error-handling mechanism, so we should optimize our terminology accordingly: Result-producing functions should be easy to describe. To update your code, rename any call to `fail!` to `panic!` instead. Assuming you have not created your own macro named `panic!`, this will work on UNIX based systems: grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g' You can of course also do this by hand. [breaking-change]

librustc: Match trait self types exactly.

2014-06-28T18:18:37+00:00

This can break code that looked like: impl Foo for Box { fn f(&self) { ... } } let x: Box = ...; x.f(); Change such code to: impl Foo for Box { fn f(&self) { ... } } let x: Box = ...; x.f(); That is, upcast before calling methods. This is a conservative solution to #5781. A more proper treatment (see the xfail'd `trait-contravariant-self.rs`) would take variance into account. This change fixes the soundness hole. Some library changes had to be made to make this work. In particular, `Box` is no longer showable, and only `Box` is showable. Eventually, this restriction can be lifted; for now, it does not prove too onerous, because `Any` is only used for propagating the result of task failure. This patch also adds a test for the variance inference work in #12828, which accidentally landed as part of DST. Closes #5781. [breaking-change]

Remove linked failure from the runtime

2013-11-25T05:21:12+00:00

The reasons for doing this are: * The model on which linked failure is based is inherently complex * The implementation is also very complex, and there are few remaining who fully understand the implementation * There are existing race conditions in the core context switching function of the scheduler, and possibly others. * It's unclear whether this model of linked failure maps well to a 1:1 threading model Linked failure is often a desired aspect of tasks, but we would like to take a much more conservative approach in re-implementing linked failure if at all. Closes #8674 Closes #8318 Closes #8863

Fix warnings it tests

2013-08-17T15:42:35+00:00