Changes the style guidelines regarding unit tests to recommend using a
sub-module named "tests" instead of "test" for unit tests as "test"
might clash with imports of libtest.

 * In noop_fold_expr, call new_span in these cases:
    - ExprMethodCall's identifier
    - ExprField's identifier
    - ExprTupField's integer

   Calling new_span for ExprMethodCall's identifier is necessary to print
   an acceptable diagnostic for write!(&2, ""). We see this error:

       <std macros>:2:20: 2:66 error: type `&mut _` does not implement any method in scope named `write_fmt`
       <std macros>:2 ( & mut * $ dst ) . write_fmt ( format_args ! ( $ ( $ arg ) * ) ) )
                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   With this change, we also see a macro expansion backtrace leading to
   the write!(&2, "") call site.

 * After fully expanding a macro, we replace the expansion expression's
   span with the original span. Call fld.new_span to add a backtrace to
   this span. (Note that I'm call new_span after bt.pop(), so the macro
   just expanded isn't on the backtrace.)

   The motivating example for this change is println!("{}"). The format
   string literal is concat!($fmt, "arg") and is inside the libstd macro.
   We need to see the backtrace to find the println! call site.

 * Add a backtrace to the format_args! format expression span.

Addresses #23459

Refactored code so that the drop-flag values for initialized
(`DTOR_NEEDED`) versus dropped (`DTOR_DONE`) are given explicit names.

Add `mem::dropped()` (which with `DTOR_DONE == 0` is semantically the
same as `mem::zeroed`, but the point is that it abstracts away from
the particular choice of value for `DTOR_DONE`).

Filling-drop needs to use something other than `ptr::read_and_zero`,
so I added such a function: `ptr::read_and_drop`.  But, libraries
should not use it if they can otherwise avoid it.

Fixes to tests to accommodate filling-drop.

This commit deprecates the majority of std::old_io::fs in favor of std::fs and
its new functionality. Some functions remain non-deprecated but are now behind a
feature gate called `old_fs`. These functions will be deprecated once
suitable replacements have been implemented.

The compiler has been migrated to new `std::fs` and `std::path` APIs where
appropriate as part of this change.

Closes #20022

upgrade the inference based on expected type so that it is able to
infer the fn kind in isolation even if the full signature is not
available (and we could perhaps do better still in some cases, such as
extracting just the types of the arguments but not the return value).

Also `for x in option.iter_mut()` -> `if let Some(ref mut x) = option`

the compiler that assumed two input types to assume two ouputs; we also have to teach `project.rs`
to project `Output` from the unboxed closure and fn traits.

Allows modifiers to be used on methods, associated types, etc.

Instead of copy-pasting the whole macro_rules! item from the original .rs file,
we serialize a separate name, attributes list, and body, the latter as
pretty-printed TTs.  The compilation of macro_rules! macros is decoupled
somewhat from the expansion of macros in item position.

This filters out comments, and facilitates selective imports.

This implements RFC 179 by making the pattern `&<pat>` require matching
against a variable of type `&T`, and introducing the pattern `&mut
<pat>` which only works with variables of type `&mut T`.

The pattern `&mut x` currently parses as `&(mut x)` i.e. a pattern match
through a `&T` or a `&mut T` that binds the variable `x` to have type
`T` and to be mutable. This should be rewritten as follows, for example,

    for &mut x in slice.iter() {

becomes

    for &x in slice.iter() {
        let mut x = x;

Due to this, this is a

[breaking-change]

Closes #20496.

This commit introduces the syntax for negative implmenetations of traits
as shown below:

`impl !Trait for Type {}`

cc #13231
Part of RFC #3

[breaking-change]

The `mut` in slices is now redundant. Mutability is 'inferred' from position. This means that if mutability is only obvious from the type, you will need to use explicit calls to the slicing methods.

Note that this doesn't add the surface syntax.

(on platforms with 64-bit pointers.)

The StmtMac variant is rather large and also fairly rare, so let's
optimise the common case.