It is now 1-based, rather than 0 based. (Seems more natural, and allows 0 to
be used to refer to self and maybe to closure.)

Also allows non-referenced args to be implicitly copied again.

Issue #918

Issue #918

Issue #918

- Loop bodies and resource constructors aren't allowed to have
  trailing expressions anymore.

- An expression that ends* in a block without trailing expression can
  can not be called, indexed, or subscripted.

- Only expression-statements that end* in a block without trailing
  expression can omit their semicolon.

*) 'Ending in a trailing expression' is defined as being a block or
   construct-ending-in-a-block (if, alt) that either ends in an
   expression itself, or ends in another block-like expression that
   has a trailing expression (by these same rules).

This will be used in the near future to decide what can safely
be done with the returned reference.

Issue #918

It will include information about returning by alias.

Blocks (or statements involving blocks) that end in a semicolon are no
longer considered the block-expression of their outer block. This used
to be an expression block, but now is a statement block:

    { if foo { ret 1; } else { ret 10; } }

This helps clear up some ambiguities in our grammar.

Closes #880

Long lines were fixed in a very crude way, as I'll be following up
with another reformat in a bit.

Upvars are now marked with def_upvar throughout, not just when going
through freevars::lookup_def. This makes things less error-prone. One
thing to watch out for is that def_upvar is used in `for each` bodies
too, when they refer to a local outside the body.

Vectors are now similar to our old, pre-internal vectors, except that
they are uniquely owned, not refcounted.

Their name should probably change too, then. I've renamed them to vec
in the runtime, will do so throughout the compiler later.

This patch supports the syntax

    unchecked {
      ...
    }

    to disable purity checking within a block. Presumably it will only be
    used within a declared "pure fn". However, there is no checking that it
    doesn't occur elsewhere, and it would be harmless for it to do so.

    I went with Lindsey's suggestion for the syntax, but it's subject to
    change.

    This allows you to write code that uses predicates that call arbitrary
    Rust functions, but you must declare your intentions by wrapping it in
    an unchecked { ... } block. The test case run-pass/unchecked-predicates.rs
    demonstrates how to do that.