tha -> than

Thanks @huonw :heart:
all/some

How could I forsake `rustdoc`? :sweat_smile:

Thanks @huonw.
staticly -> statically

What's funny about this one is that spellcheck caught it, but for
some reason didn't give me the right suggestion, so I assumed that it
wasn't in my dictionary. Oh well.

Thanks @P1start! :heart:
Fix IRC linkage.

Death to `here`!

Thanks @chris-morgan :heart:
StackOverflow -> Stack Overflow

Thanks @chris-morgan
Fixing link to subreddit.

Thanks @chris-morgan :heart:
Move note about $ up

Thanks @chris-morgan :heart:
rustrt: Reorganize task usage

Most of the comments are available on the Task structure itself, but this commit
is aimed at making FFI-style usage of Rust tasks a little nicer.

Primarily, this commit enables re-use of tasks across multiple invocations. The
method `run` will no longer unconditionally destroy the task itself. Rather, the
task will be internally re-usable if the closure specified did not fail. Once a
task has failed once it is considered poisoned and it can never be used again.

Along the way I tried to document shortcomings of the current method of tearing
down a task, opening a few issues as well. For now none of the behavior is a
showstopper, but it's useful to acknowledge it. Also along the way I attempted
to remove as much `unsafe` code as possible, opting for safer abstractions.
TIL PATHEXT

Thanks @chris-morgan :heart:
Clarify which curly is being referred to

Thanks @chris-morgan
Note that macros != templates

Good call, @chris-morgan and @cmr!
auto merge of #14886 : alexcrichton/rust/rt-improvements, r=brson

Most of the comments are available on the Task structure itself, but this commit
is aimed at making FFI-style usage of Rust tasks a little nicer.

Primarily, this commit enables re-use of tasks across multiple invocations. The
method `run` will no longer unconditionally destroy the task itself. Rather, the
task will be internally re-usable if the closure specified did not fail. Once a
task has failed once it is considered poisoned and it can never be used again.

Along the way I tried to document shortcomings of the current method of tearing
down a task, opening a few issues as well. For now none of the behavior is a
showstopper, but it's useful to acknowledge it. Also along the way I attempted
to remove as much `unsafe` code as possible, opting for safer abstractions.
Fix missing word and some grammar

Thanks @chris-morgan and @P1start! :heart:
C macros, not C++ templates.

@cmr rightfully points out that C macros are worse, and share the
same name.
std::io: Use re-exported pathes in examples.

We use re-exported pathes (e.g. std::io::Command) and original ones
(e.g. std::io::process::Command) together in examples now. Using
re-exported ones consistently avoids confusion.

Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
librustc: Ensure that proc upvars have static lifetime.

Since procs do not have lifetime bounds, we must do this to maintain
safety.

This can break code that incorrectly captured references in procedure
types. Change such code to not do this, perhaps with a trait object
instead.

A better solution would be to add higher-rank lifetime support to procs.
However, this would be a lot of work for a feature we want to remove in
favor of unboxed closures. The corresponding "real fix" is #15067.

Closes #14036.

[breaking-change]
auto merge of #15190 : pcwalton/rust/proc-upvars, r=alexcrichton

Since procs do not have lifetime bounds, we must do this to maintain
safety.

This can break code that incorrectly captured references in procedure
types. Change such code to not do this, perhaps with a trait object
instead.

Closes #14036.

[breaking-change]

r? @alexcrichton
README: Add instructions for building on windows.
auto merge of #15206 : omasanori/rust/use-reexported, r=alexcrichton

We use re-exported pathes (e.g. std::io::Command) and original ones
(e.g. std::io::process::Command) together in examples now. Using
re-exported ones consistently avoids confusion.
Fix windows run instructions

Thank you, @stormbrew!