Conflicts:
	src/libsyntax/feature_gate.rs

This commit tweaks the interface of the `std::env` module to make it more
ergonomic for common usage:

* `env::var` was renamed to `env::var_os`
* `env::var_string` was renamed to `env::var`
* `env::args` was renamed to `env::args_os`
* `env::args` was re-added as a panicking iterator over string values
* `env::vars` was renamed to `env::vars_os`
* `env::vars` was re-added as a panicking iterator over string values.

This should make common usage (e.g. unicode values everywhere) more ergonomic
as well as "the default". This is also a breaking change due to the differences
of what's yielded from each of these functions, but migration should be fairly
easy as the defaults operate over `String` which is a common type to use.

[breaking-change]

Fixes issue #22174.

When projecting associate types for a trait's default methods, the
trait itself was added to the predicate candidate list twice: one from
parameter environment, the other from trait definition. Then the
duplicates were deemed as code ambiguity and the compiler rejected the
code. Simply checking and dropping the duplicates solves the issue.

Closes #22036

This resulted in some very unexpected fallout such as empty llvm-ir, llvm-bc and asm in some cases.
See #22183 for related info.

r? @alexcrichton

OpenBSD doesn't have thread-local-storage support (yet).
Permit to compile (and run) `check-stage1-crates` under OpenBSD.

Fixes #21062.

It doesn't have to be a literal memory allocation (ala malloc), e.g. it
can be in static memory, so saying "allocated" is mildly misleading.

Thanks to @mahkoh for pointing it out.

r? @steveklabnik

It returns `false`, not `None`.

Given that this is entirely internal, this enhancement isn't going to be needed. And if it is, we'll add it.

Closes #2741.

r? @alexcrichton

Fixes #22124

There are a number of holes that the stability lint did not previously cover,
including:

* Types
* Bounds on type parameters on functions and impls
* Where clauses
* Imports
* Patterns (structs and enums)

These holes have all been fixed by overriding the `visit_path` function on the
AST visitor instead of a few specialized cases. This change also necessitated a
few stability changes:

* The `collections::fmt` module is now stable (it was already supposed to be).
* The `thread_local::imp::Key` type is now stable (it was already supposed to
  be).
* The `std::rt::{begin_unwind, begin_unwind_fmt}` functions are now stable.
  These are required via the `panic!` macro.
* The `std::old_io::stdio::{println, println_args}` functions are now stable.
  These are required by the `print!` and `println!` macros.
* The `ops::{FnOnce, FnMut, Fn}` traits are now `#[stable]`. This is required to
  make bounds with these traits stable. Note that manual implementations of
  these traits are still gated by default, this stability only allows bounds
  such as `F: FnOnce()`.

Closes #8962
Closes #16360
Closes #20327

The live code analysis only visited the function's body when visiting a
method, and not the FnDecl and the generics, resulting in code to be
incorrectly marked as unused when it only appeared in the generics, the
arguments, or the return type, whereas the same code in non-method
functions was correctly detected as used. Fixes #20343.

Originally I just added a call to `walk_generics` and `walk_fndecl` alongside `walk_block` but then I noticed the `walk_method_helper` function did pretty much the same thing. The only difference is that it also calls `visit_mac`, but since this is not going to happen at this stage, I think it's ok. However let me know if this was not the right thing to do.

This renames the PrivateNoMangleFns lint to allow both to happen in a
single pass, since they do roughly the same work.

Closes #21856

Open questions:

[ ]: Do the tests actually pass (I'm running make check and running out the door now)
[ ]: Is the name of this lint ok. it seems to mostly be fine with [convention](https://github.com/rust-lang/rfcs/blob/cc53afbe5dea41e1f7d1c3dce71e013abe025211/text/0344-conventions-galore.md#lints)
[ ]: I'm not super thrilled about the warning text

r? @kmcallister (Shamelessly nominating because you were looking at my other ticket)

This commit tweaks the interface of the `std::env` module to make it more
ergonomic for common usage:

* `env::var` was renamed to `env::var_os`
* `env::var_string` was renamed to `env::var`
* `env::args` was renamed to `env::args_os`
* `env::args` was re-added as a panicking iterator over string values
* `env::vars` was renamed to `env::vars_os`
* `env::vars` was re-added as a panicking iterator over string values.

This should make common usage (e.g. unicode values everywhere) more ergonomic
as well as "the default". This is also a breaking change due to the differences
of what's yielded from each of these functions, but migration should be fairly
easy as the defaults operate over `String` which is a common type to use.

[breaking-change]

There are a number of holes that the stability lint did not previously cover,
including:

* Types
* Bounds on type parameters on functions and impls
* Where clauses
* Imports
* Patterns (structs and enums)

These holes have all been fixed by overriding the `visit_path` function on the
AST visitor instead of a few specialized cases. This change also necessitated a
few stability changes:

* The `collections::fmt` module is now stable (it was already supposed to be).
* The `thread_local::imp::Key` type is now stable (it was already supposed to
  be).
* The `std::rt::{begin_unwind, begin_unwind_fmt}` functions are now stable.
  These are required via the `panic!` macro.
* The `std::old_io::stdio::{println, println_args}` functions are now stable.
  These are required by the `print!` and `println!` macros.
* The `ops::{FnOnce, FnMut, Fn}` traits are now `#[stable]`. This is required to
  make bounds with these traits stable. Note that manual implementations of
  these traits are still gated by default, this stability only allows bounds
  such as `F: FnOnce()`.

Additionally, the compiler now has special logic to ignore its own generated
`__test` module for the `--test` harness in terms of stability.

Closes #8962
Closes #16360
Closes #20327

[breaking-change]

This is a resurrection and heavy revision/expansion of a PR that pcwalton did to resolve #8861.

The most relevant, user-visible semantic change is this: #[unsafe_destructor] is gone. Instead, if a type expression for some value has a destructor, then any lifetimes referenced within that type expression must strictly outlive the scope of the value.

See discussion on https://github.com/rust-lang/rfcs/pull/769

This resulted in some very unexpected fallout such as empty llvm-ir, llvm-bc and asm in some cases.
See #22183 for related info.

When projecting associate types for a trait's default methods, the
trait itself was added to the predicate candidate list twice: one from
parameter environment, the other from trait definition. Then the
duplicates were deemed as code ambiguity and the compiler rejected the
code. Simply checking and dropping the duplicates solves the issue.

Closes #22036

Feature gate `box` patterns.

Note that this adds a new feature gate, `box_patterns` specific to e.g. `let box i = ...`, while leaving  `box` expressions (alone) still guarded via the preexisting `box_syntax`.

just say "experimental."

See RFC 320, "Non-zeroing dynamic drops."

Fix #22173

[breaking-change]

It (1.) is invariant, (2.) must strictly outlive the arena itself,
(3.) constrains the inputs to the arena so that their borrows must
also strictly outlive the arena itself.

This implies that, for now, one can no longer have cross-references
between data allocated via the same `Arena` (even when the data is not
subject to the Drop Check rule).  Instead one must carry multiple
`Arena` instances, or (more commonly), use one or more `TypedArena`
instances with enums encoding the different variants of allocated
data.

Some compile-fail tests illustrated cases to be rejected by dropck,
including ones that check cyclic data cases designed to exposed bugs
if they are actually tricked into running by an unsound analysis.

E.g. these exposed bugs in earlier broken ways of handling `Vec<T>`.

(Note that all the uses of `unsafe_destructor` are just placating the
simple analysis used for that feature, which will eventually go away
once we have put the dropck through its paces.)

includes regression tests discovered during bootstrapping and tests of
cyclic structure that currently pass and are expected to continue
passing under the dropck rule.

(Note that all the uses of `unsafe_destructor` are just placating the
simple analysis used for that feature, which will eventually go away
once we have put the dropck through its paces.)

Handles e.g. `impl<T> Drop for Vec<T>` as parametric: If `T` does not
have any drop code that could read from borrowed data of lifetime `'a`,
then we infer that the drop code for `Vec<T>` also cannot read from
borrowed data of lifetime `'a`, and therefore we do not need to inject
the SafeDestructor constraint for it.

Notably, this enables us to continue storing cyclic structure, without
any `unsafe` code, in `Vec`, without allowing (unsound) destructors on
such cyclic data. (Later commits have tests illustrating these two
cases in run-pass and compile-fail, respectively.)

(This is "Condition (B.)" in Drop-Check rule described in RFC 769.)

Port `core::ptr::Unique` to have `PhantomData`. Add `PhantomData` to
`TypedArena` and `Vec` as well.

As a drive-by, switch `ptr::Unique` from a tuple-struct to a struct
with fields.

Namely: `collections` (used in `dlist.rs`), `syntax`, `rustc`,
`rustc_typeck`, `rustc_trans`, and `rustdoc`.

Switch feature-gate checker from `box_syntax` to `box_patterns` when
visiting a pattern.

(Having to opt into both `box_syntax` and `box_patterns` seemed
unnecessary.)

[breaking-change]

`make docs` fails when (xe)latex is not installed. The output is pretty weird, looks like it's doing some `eval` tricks but something is blank:

    /bin/sh: -output-directory=.: command not found
    /home/tim/dev/rust/rust/mk/docs.mk:220: recipe for target 'doc/reference.pdf' failed

I have neither latex or xelatex installed. It seems like the following snippet is meant for me, but the logic is backwards:

    ifeq ($(CFG_XELATEX),)
        CFG_LATEX := $(CFG_XELATEX)
        XELATEX = 1
      else
        $(info cfg: no xelatex found, disabling LaTeX docs)
        NO_PDF_DOCS = 1
    endif

I verified with:

    $ make doc/reference.pdf CFG_XELATEX=/bin/foo
    cfg: no xelatex found, disabling LaTeX docs

Fixes #22124

Largely adapted from pcwalton's original branch, with following
notable modifications:

Use `regionck::type_must_outlive` to generate `SafeDestructor`
constraints.  (this plugged some soundness holes in the analysis).

Avoid exponential time blowup on compile-fail/huge-struct.rs by
keeping the breadcrumbs until end of traversal.

Avoid premature return from regionck::visit_expr.

Factored drop-checking code out into dropck module.

Added `SafeDestructor` to enum `SubregionOrigin` (for error reporting).

----

Since this imposes restrictions on the lifetimes used in types with
destructors, this is a (wait for it)

[breaking-change]