When printing colored diagnostics, we need to reset the terminal before
emitting the newline, not after. Otherwise it gets line-buffered and the
color won't reset until the next line is printed or the compiler exits.

Normally this isn't a problem, but when running rustc in parallel with
other processes (e.g. `make -j4`) this can cause the color to leak
to other lines.

Closes #14278.

Previously the type signatures of the ordering functions in `core::iter::order` took two iterators, but only if they were the same type of iterator.  This commit loosens that restriction and allows different kinds of iterators (but with the same type of elements) to be compared.

This is hard coding `Box` into this, as it doesn't seem to parse as `TyUniq` like `~` did. This may not be correct for all usages of the box keyword. 

Closes #14254.

When printing colored diagnostics, we need to reset the terminal before
emitting the newline, not after. Otherwise it gets line-buffered and the
color won't reset until the next line is printed or the compiler exits.

Normally this isn't a problem, but when running rustc in parallel with
other processes (e.g. `make -j4`) this can cause the color to leak
to other lines.

Previously the type signatures of the ordering functions in
`core::iter::order` took two iterators, but only if they were
the same type of iterator.  This commit loosens that restriction
and allows different kinds of iterators (but with the same type
of elements) to be compared.

The `init_to_vec` function in `collections::bitv` was exposed as an
inherent method, but appears to just be a helper function for the
`to_vec` method. This patch inlines the definition, removing
`init_to_vec` from the public API.

[breaking-change]

This has no tests because it's near impossible to test -- since TestFn uses
`proc`s, they can not be cloned or tested for equality. The only way to really
test this is making sure that for a given number of shards `a`, sharding from
1 to `a` yields the complete set of tests. But `filter_tests` takes its vector
by value and `proc`s cannot be compared.

[breaking-change]

Closes #10898

This has no tests because it's near impossible to test -- since TestFn uses
`proc`s, they can not be cloned or tested for equality. The only way to really
test this is making sure that for a given number of shards `a`, sharding from
1 to `a` yields the complete set of tests. But `filter_tests` takes its vector
by value and `proc`s cannot be compared.

[breaking-change]

Closes #10898

The `init_to_vec` function in `collections::bitv` was exposed as an
inherent method, but appears to just be a helper function for the
`to_vec` method. This patch inlines the definition, removing
`init_to_vec` from the public API.

[breaking-change]

Result.unwrap_or_handle() is the equivalent of Option.unwrap_or_else().
In the interests of naming consistency, call it the same thing.

[breaking-change]

Result.unwrap_or_handle() is the equivalent of Option.unwrap_or_else().
In the interests of naming consistency, call it the same thing.

[breaking-change]

The breaking changes are:

* Changed `DList::insert_ordered` to use `TotalOrd`, not `Ord`
* Changed `PriorityQueue` to use `TotalOrd`, not `Ord`
* Deprecated `PriorityQueue::maybe_top()` (renamed to replace `PriorityQueue::top()`)
* Deprecated `PriorityQueue::maybe_pop()` (renamed to replace `PriorityQueue::pop()`)
* Deprecated `PriorityQueue::to_vec()` (renamed to `PriorityQueue::into_vec()`)
* Deprecated `PriorityQueue::to_sorted_vec()` (renamed to `PriorityQueue::into_sorted_vec()`)
* Changed `PriorityQueue::replace(...)` to return an `Option<T>` instead of failing when the queue is empty.


[breaking-change]

This is an implementation of RFC 16. A module can now only be loaded if the
module declaring `mod name;` "owns" the current directory. A module is
considered as owning its directory if it meets one of the following criteria:

* It is the top-level crate file
* It is a `mod.rs` file
* It was loaded via `#[path]`
* It was loaded via `include!`
* The module was declared via an inline `mod foo { ... }` statement

For example, this directory structure is now invalid

    // lib.rs
    mod foo;

    // foo.rs
    mod bar;

    // bar.rs;
    fn bar() {}

With this change `foo.rs` must be renamed to `foo/mod.rs`, and `bar.rs` must be
renamed to `foo/bar.rs`. This makes it clear that `bar` is a submodule of `foo`,
and can only be accessed through `foo`.

RFC: 0016-module-file-system-hierarchy
Closes #14180

[breaking-change]

This is my first patch and hopefully nothing controversial: just a straightforward forwarding of TreeMap::move_iter() as TreeSet::move_iter().

Fix #13732.

This is a revised, much less hacky form of PR #13753

The changes here:

 * add instrumentation to aid debugging of linkage errors,
 * fine tune some things in the Makefile where we are telling binaries to use a host-oriented path for finding dynamic libraries, when it should be feeding the binaries a target-oriented path for dynamic libraries.
 * pass along the current stage number to run-make tests, and
 * skip certain tests when running atop stage1.

Fix #13746 as well.

Two line summary: Distinguish HOST_RPATH and TARGET_RPATH; added
RPATH_LINK_SEARCH; skip tests broken in stage1; general cleanup.

`HOST_RPATH_VAR$(1)_T_$(2)_H_$(3)` and `TARGET_RPATH_VAR$(1)_T_$(2)_H_$(3)`
both match the format of the old `RPATH_VAR$(1)_T_$(2)_H_$(3)` (which
is still being set the same way that it was before, to one of either
HOST/TARGET depending on what stage we are building).  Namely, the format
is <XXX>_RPATH_VAR = "<LD_LIB_PATH_ENVVAR>=<COLON_SEP_PATH_ENTRIES>"

What this commit does:

* Pass both of the (newly introduced) HOST and TARGET rpath setup vars
  to `maketest.py`

* Update `maketest.py` to no longer update the LD_LIBRARY_PATH itself
  Instead, it passes along the HOST and TARGET rpath setup vars in
  environment variables `HOST_RPATH_ENV` and `TARGET_RPATH_ENV`

* Also, pass the current stage number to maketest.py; it in turn
  passes it (via an env var) to run-make tests.

  This allows the run-make tests to selectively change behavior
  (e.g. turn themselves off) to deal with incompatibilities with
  e.g. stage1.

* Cleanup: Distinguish in tools.mk between the command to run (`RUN`)
  and the file to generate to drive that command (`RUN_BINFILE`).  The
  main thing this enables is that `RUN` can now setup the
  `TARGET_RPATH_ENV` without having to dirty up the runner code in
  each of the `run-make` Makefiles.

* Cleanup: Factored out commands to delete dylib/rlib into
  REMOVE_DYLIBS/REMOVE_RLIBS.

  There were places where we were only calling `rm $(call DYLIB,foo)`
  even though we really needed to get rid of the whole glob (at least
  based on alex's findings on #13753 that removing the symlink does not
  suffice).

  Therefore rather than peppering the code with the awkward
  `rm $(TMPDIR)/$(call DYLIB_GLOB,foo)`, I instead introduced a common
  `REMOVE_DYLIBS` user function that expands into that when called.
  After I adding an analogous `REMOVE_RLIBS`, I changed all of the
  existing calls that rm dylibs or rlibs to use these routines
  instead.

  Note that the latter is not a true refactoring since I may have
  changed cases where it was our intent to only remove the sym-link.
  (But if that is the case, then we need to more deeply investigate
  alex's findings on #13753 where the system was still dynamically
  loading up the non-symlinked libraries that it finds on the load
  path.)

* Added RPATH_LINK_SEARCH command and use it on Linux.

  On some platforms, namely Linux, when you have libboot.so that has
  its internal rpath set (to e.g. $(ORIGIN)/path/to/HOSTDIR), the
  linker still complains when you do the link step and it does not
  know where to find libraries that libboot.so depends upon that live
  in HOSTDIR (think e.g. librustuv.so).

  As far as I can tell, the GNU linker will consult the
  LD_LIBRARY_PATH as part of the linking process to find such
  libraries.  But if you want to be more careful and not override
  LD_LIBRARY_PATH for the `gcc` invocation, then you need some other
  way to tell the linker where it can find the libraries that
  libboot.so needs.  The solution to this on Linux is the
  `-Wl,-rpath-link` command line option.

  However, this command line option does not exist on Mac OS X, (which
  appears to be figuring out how to resolve the libboot.dylib
  dependency by some other means, perhaps by consulting the rpath
  setting within libboot.dylib).

  So, in order to abstract over this distinction, I added the
  RPATH_LINK_SEARCH macro to the run-make infrastructure and added
  calls to it where necessary to get Linux working.  On architectures
  other than Linux, the macro expands to nothing.

* Disable miscellaneous tests atop stage1.

* An especially interesting instance of the previous bullet point:
  Excuse regex from doing rustdoc tests atop stage1.

  This was a (nearly-) final step to get `make check-stage1` working
  again.

  The use of a special-case check for regex here is ugly but is
  analogous other similar checks for regex such as the one that landed
  in PR #13844.

  The way this is written, the user will get a reminder that
  doc-crate-regex is being skipped whenever their rules attempt to do
  the crate documentation tests.  This is deliberate: I want people
  running `make check-stage1` to be reminded about which cases are
  being skipped.  (But if such echo noise is considered offensive, it
  can obviously be removed.)

* Got windows working with the above changes.

  This portion of the commit is a cleanup revision of the (previously
  mentioned on try builds) re-architecting of how the LD_LIBRARY_PATH
  setup and extension is handled in order to accommodate Windows' (1.)
  use of `$PATH` for that purpose and (2.) use of spaces in `$PATH`
  entries (problematic for make and for interoperation with tools at
  the shell).

* In addition, since the code has been rearchitected to pass the
  HOST_RPATH_DIR/TARGET_RPATH_DIR rather than a whole sh
  environment-variable setting command, there is no need to for the
  convert_path_spec calls in maketest.py, which in fact were put in
  place to placate Windows but were now causing the Windows builds to
  fail.  Instead we just convert the paths to absolute paths just like
  all of the other path arguments.

Also, note for makefile hackers: apparently you cannot quote operands
to `ifeq` in Makefile (or at least, you need to be careful about
adding them, e.g. to only one side).

See #13983 and #14000.

Fix was originally authored by alexcrichton and then rebased a couple
times by pnkfelix, most recently atop PR 13954.

----

Regarding the change to librustdoc/lib.rs, to do `map_err` before
unwrapping a `TqskResult`: I do not understand how master is passing
without this change or something like it, since `Box<Any:Send>` does
not implement `Show`.  (Is this something that is only a problem for
the snapshot stage0 compiler?)  Still, the change I have put in here
(which was added as part of a rebase after alex's review) seems
harmless to me to apply to rustdoc at all stages, since a call to
`unwrap` is just going to `fail!` on the err case anyway.

Change `bytes!()` to return

    {
        static BYTES: &'static [u8] = &[...];
        BYTES
    }

This gives it the `'static` lifetime, whereas before it had an rvalue
lifetime. Until recently this would have prevented assigning `bytes!()`
to a static, as in

    static FOO: &'static [u8] = bytes!(1,2,3);

but #14183 fixed it so blocks are now allowed in constant expressions
(with restrictions).

Fixes #11641.

Change `bytes!()` to return

    {
        static BYTES: &'static [u8] = &[...];
        BYTES
    }

This gives it the `'static` lifetime, whereas before it had an rvalue
lifetime. Until recently this would have prevented assigning `bytes!()`
to a static, as in

    static FOO: &'static [u8] = bytes!(1,2,3);

but #14183 fixed it so blocks are now allowed in constant expressions
(with restrictions).

Fixes #11641.

This commit fills in the documentation holes for the FormatWriter trait which
were previously accidentally left blank. Additionally, this adds the `write_fmt`
method to the trait to allow usage of the `write!` macro with implementors of
the `FormatWriter` trait. This is not useful for consumers of the standard
library who should generally avoid the `FormatWriter` trait, but it is useful
for consumers of the core library who are not using the standard library.