Fix issue #8763

* added case & better error message for "impl trait for module"
* used better way to print the module
* switched from //error-pattern to //~ ERROR
* added compile-fail test trait-impl-for-module.rs
* revised compile-fail test trait-or-new-type-instead
    (the error message for the modified test is still unclear, but that's a different bug)
* added FIXME to trait-or-new-type-instead
auto merge of #10475 : astrieanna/rust/issue8763, r=alexcrichton

Issue #8763 is about improving a particular error message.

* added case & better error message for "impl trait for module"
* added compile-fail test trait-impl-for-module.rs
* updated copyright dates
* revised compile-fail test trait-or-new-type-instead
   (the error message for the modified test is still unclear, but that's a different bug https://github.com/mozilla/rust/issues/8767)
std::trie: Fix find_mut for non-present keys

Make TrieMap/TrieSet's find_mut check the key for external nodes.
Without this find_mut sometimes returns a reference to another key when
querying for a non-present key.
libextra: Remove @mut from term.
Add comments to ast, ast_map, ty, and pat_util
auto merge of #10600 : ktt3ja/rust/add-doc, r=huonw

I received a lot of helpful explanations when I was going through rustc's middle-end code. I document some of them here.
Add a note for unclosed delimiters

Currently, the parser doesn't give any context when it finds an unclosed
delimiter and it's not EOF. Report the most recent unclosed delimiter, to help
the user along.

Closes #10636
auto merge of #10637 : luqmana/rust/nmt, r=cmr

There's no need for it to be @mut.
auto merge of #10639 : jix/rust/fix_find_mut_in_trie, r=thestinger

Make TrieMap/TrieSet's find_mut check the key for external nodes.
Without this find_mut sometimes returns a reference to another key when
querying for a non-present key.
Fix spelling of "vacuum" in one of the abort quotes.
rustdoc: pass through --cfg to rustc

Closes #10623
Remove linked failure from the runtime

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
Cache a task's stderr logger

This is both useful for performance (otherwise logging is unbuffered), but also
useful for correctness. Because when a task is destroyed we can't block the task
waiting for the logger to close, loggers are opened with a 'CloseAsynchronously'
specification. This causes libuv do defer the call to close() until the next
turn of the event loop.

If you spin in a tight loop around printing, you never yield control back to the
libuv event loop, meaning that you simply enqueue a large number of close
requests but nothing is actually closed. This queue ends up never getting
closed, meaning that if you keep trying to create handles one will eventually
fail, which the runtime will attempt to print the failure, causing mass
destruction.

Caching will provide better performance as well as prevent creation of too many
handles.

Closes #10626
auto merge of #10603 : alexcrichton/rust/no-linked-failure, r=brson

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
Set uv's custom data before uv_read_start

This is a behavioral difference in libuv between different platforms in
different situations. It turns out that libuv on windows will immediately
allocate a buffer instead of waiting for data to be ready. What this implies is
that we must have our custom data set on the handle before we call
uv_read_start.

I wish I knew of a way to test this, but this relies to being on the windows
platform *and* reading from a true TTY handle which only happens when this is
actually attached to a terminal. I have manually verified this works.

Closes #10645
auto merge of #10635 : alexcrichton/rust/issue-10626, r=cmr

This is both useful for performance (otherwise logging is unbuffered), but also
useful for correctness. Because when a task is destroyed we can't block the task
waiting for the logger to close, loggers are opened with a 'CloseAsynchronously'
specification. This causes libuv do defer the call to close() until the next
turn of the event loop.

If you spin in a tight loop around printing, you never yield control back to the
libuv event loop, meaning that you simply enqueue a large number of close
requests but nothing is actually closed. This queue ends up never getting
closed, meaning that if you keep trying to create handles one will eventually
fail, which the runtime will attempt to print the failure, causing mass
destruction.

Caching will provide better performance as well as prevent creation of too many
handles.

Closes #10626
auto merge of #10641 : cmr/rust/close_delims, r=alexcrichton

Currently, the parser doesn't give any context when it finds an unclosed
delimiter and it's not EOF. Report the most recent unclosed delimiter, to help
the user along.

Closes #10636
Fix typo in base64 test

We want a 1000 element array, not a 2 element array
syntax: parse inner attributes on impls.

Fixes #3614.
auto merge of #10628 : huonw/rust/3614, r=alexcrichton

Fixes #3614.