Contributing.md: remove spurious verb
docs/rust.md: Mention unit-like structs along with other struct types
doc/rust.md: Demonstrate the `f::<T>()` syntax more often

The "Generic functions" subsection mentions that generic functions are
instantiated based on context, so let's also mention right away (with a
link to the #paths section) that an explicit form is available.

This also adds an example to the function call expression section that
explicitly instantiates a generic function.
core: Move core::rt to core::unstable::lang
Fix some struct-tuple def prettyprint issues
- Removed space between struct name and parentheses
- Fixed indentation of the rest of the file (missing end)
- Don't print parentheses for structs with no fields
- Added test
Remove REC, change related tests/docs
auto merge of #5186 : ben0x539/rust/contributing, r=brson

I'm wary of editing the offical-looking things like the contribution policy, but I hope fixing typos/the sentence structure is okay.
auto merge of #5187 : ben0x539/rust/docs-unit-struct, r=catamorphism

This adds a few words about unit-like struct types (`struct Foo;`) in the sections for `struct` items, structure expressions and structure types (and fixes an adjacent typo or two). The added text is at the same time triply redundant because of how the sections are split and rather brief because I don't think there's that much to say about field-less structs without digressing into `impl`s and generic functions and whatnot, but it's probably better than nothing for a start.

The added arm for the grammar of struct expressions is really awkward. It's just

    | expr_path

which is clearly not unambiguously a struct expression, but it didn't feel right not to add anything to the grammar chunk (and I can't tell whether the arm for enum-like structs is somehow unambiguous with regular enum expressions, either). Is this okay?
auto merge of #5188 : ben0x539/rust/doc-call-generic-fn, r=catamorphism

I have seen a few people confused on how to explicitly instantiate generic functions, since the syntax differs from C++'s and C#'s, which is probably where most people asking questions about generic functions are coming from. The only use of the `::<T>` syntax in the reference right now is in the section on paths, which is possibly not where someone trying to find out about generic functions is going to start looking. The tutorial doesn't mention it at all, but I think it's all right to make the reference a tiny bit more redundant and avoid stuffing the tutorial with syntax details.

----

The "Generic functions" subsection mentions that generic functions are instantiated based on context, so let's also mention right away (with a link to the #paths section) that an explicit form is available.

This also adds an example that explicitly instantiates a generic function to the function call expression section.
auto merge of #5191 : brson/rust/movert, r=brson

Moving them out of the way so the new scheduler code can occupy core::rt.
auto merge of #5193 : sethpink/rust/struct-tup-pp, r=catamorphism

- Removed space between struct name and parentheses
- Fixed indentation of the rest of the file (missing end)
- Don't print parentheses for structs with no fields
- Added test
auto merge of #5137 : yjh0502/rust/empty_struct, r=nikomatsakis

The fix is straight-forward, but there are several changes
while fixing the issue.

1) disallow `mut` keyword when making a new struct

In code base, there are following code,

```rust
struct Foo { mut a: int };
let a = Foo { mut a: 1 };
```

This is because of structural record, which is
deprecated corrently (see issue #3089) In structural
record, `mut` keyword should be allowd to control
mutability. But without structural record, we don't
need to allow `mut` keyword while constructing struct.

2) disallow structural records in parser level
This is related to 1). With structural records, there
is an ambiguity between empty block and empty struct
To solve the problem, I change parser to stop parsing
structural records. I think this is not a problem,
because structural records are not compiled already.

Misc. issues

There is an ambiguity between empty struct vs. empty match stmt.
with following code,

```rust
match x{} {}
```

Two interpretation is possible, which is listed blow

```rust
match (x{}) {} //  matching with newly-constructed empty struct
(match x{}) {}  //  matching with empty enum(or struct) x
                //  and then empty block
```

It seems that there is no such code in rust code base, but
there is one test which uses empty match statement:
https://github.com/mozilla/rust/blob/incoming/src/test/run-pass/issue-3037.rs

All other cases could be distinguished with look-ahead,
but this can't be. One possible solution is wrapping with
parentheses when matching with an uninhabited type.

```rust
enum what { }
fn match_with_empty(x: what) -> ~str {
    match (x) { //use parentheses to remove the ambiguity
    }
}
```