This fixes a double word typo, 'of'.

See https://github.com/rust-lang/rfcs/pull/16 and https://github.com/rust-lang/rust/issues/15701

- Added syntax support for attributes on expressions and all syntax nodes in statement position.
- Extended `#[cfg]` folder to allow removal of statements, and
of expressions in optional positions like expression lists and trailing
block expressions.
- Extended lint checker to recognize lint levels on expressions and
locals.
- As per RFC, attributes are not yet accepted on `if` expressions.

Examples:
  ```rust
let x = y;
{
        ...
}
assert_eq!((1, #[cfg(unset)] 2, 3), (1, 3));

let FOO = 0;
```

Implementation wise, there are a few rough corners and open questions:
- The parser work ended up a bit ugly.
- The pretty printer change was based mostly on guessing.
- Similar to the `if` case, there are some places in the grammar where a new `Expr` node starts,
  but where it seemed weird to accept attributes and hence the parser doesn't. This includes:
  - const expressions in patterns
  - in the middle of an postfix operator chain (that is, after `.`, before indexing, before calls)
  - on range expressions, since `#[attr] x .. y` parses as  `(#[attr] x) .. y`, which is inconsistent with
    `#[attr] .. y` which would parse as `#[attr] (.. y)`
- Attributes are added as additional `Option<Box<Vec<Attribute>>>` fields in expressions and locals.
- Memory impact has not been measured yet.
- A cfg-away trailing expression in a block does not currently promote the previous `StmtExpr` in a block to a new trailing expr. That is to say, this won't work:
```rust
let x = {
    #[cfg(foo)]
    Foo { data: x }
    #[cfg(not(foo))]
    Foo { data: y }
};
```
- One-element tuples can have their inner expression removed to become Unit, but just Parenthesis can't. Eg, `(#[cfg(unset)] x,) == ()` but `(#[cfg(unset)] x) == error`. This seemed reasonable to me since tuples and unit are type constructors, but could probably be argued either way.
- Attributes on macro nodes are currently unconditionally dropped during macro expansion, which seemed fine since macro disappear at that point?
- Attributes on `ast::ExprParens` will be prepend-ed to the inner expression in the hir folder.
- The work on pretty printer tests for this did trigger, but not fix errors regarding macros:
  - expression `foo![]` prints as `foo!()`
  - expression `foo!{}` prints as `foo!()`
  - statement `foo![];` prints as `foo!();`
  - statement `foo!{};` prints as `foo!();`
  - statement `foo!{}` triggers a `None` unwrap ICE.

Replace the old link pointing to an out-of-date gist with a
link to the lazy_static crate on crates.io.

We also don't need to state the author, as the crates.io page
shows the authors and owners.

This fixes it so the Rust allocator on Windows 32-bit doesn't think the system allocator is aligned to 16 when it is really only aligned to 8.

Fixes #30109

The local item-path includes the local crates path to the extern crate
declaration which breaks cross-crate rustdoc links if the extern crate
is not linked into the crate root or renamed via `extern foo as bar`.

This flag causes the documentation for all `aux-build` files to
be built, which happens prior to running/building the parent test.

This removes a number of instances of unwrap and replaces them with
pattern matching.

This is in response to rust issue #29992.

Replace the old link pointing to an out-of-date gist with a
link to the lazy_static crate on crates.io.

We also don't need to state the author, as the crates.io page
shows the authors and owners.

r? @Manishearth

s/isize/i32

Don't think there are any known regressions, but then I am still way behind on my GH notifications. cc @rust-lang/compiler thoughts?

This brings across changes made to the term library to libterm. This
includes removing instances or unwrap, fixing format string handling, and
removing a TODO.

This fix does not bring all changes across, as term now relies on cargo
deps that cannot be brought into the rust build at this stage, but has
attempted as best to cross port changes not relying on this. This notably
limits extra functionality since implemented int he Terminal trait in
Term.

This is in partly in response to rust issue #29992.

Keeping this file up to date requires hours of work every release,
even with the script. It is a fool's errand and we shall not do it
any longer.

Signed-off-by: NPeter Atashian <retep998@gmail.com>

This pass causes mis-optimizations in some cases and is probably no
longer really important for us, so let's disable it for now.

Fixes #30081

Keeping this file up to date requires hours of work every release,
even with the script. It is a fool's errand and we shall not do it
any longer.

Part of #29376

r? @nikomatsakis

This pass causes mis-optimizations in some cases and is probably no
longer really important for us, so let's disable it for now.

Fixes #30081

Part of #29376

r? @steveklabnik

This dates from the stone-ages. We always configure LLVM with all
supported targets.

- Successful merges: #30129, #30134, #30136, #30144, #30150, #30153, #30154
- Failed merges:

This dates from the stone-ages. We always configure LLVM with all
supported targets.

The text mentions ```return```, but what's actually happening is a ```panic!```.

I think this fixes #30137. I basically just repeated some details that were scattered around other places in this document, and emphasized that you probably don't want an `extern crate` or `mod` statement to end up inside a function.