If an enum is isomorphic to unit, there's no need to use any bits to
represent it.  The only obvious reason this wasn't the case was because
the enum could be C-like and have a user-specified discriminant -- but
that value is constant, so it doesn't need to be stored.

This change means that all newtype-like enums have the same size (and
layout) as their underlying type, which might be a useful property to
have, at least in terms of making programs' low-level behavior less
surprising.

If an enum is isomorphic to unit, there's no need to use any bits to
represent it.  The only obvious reason this wasn't the case was because
the enum could be C-like and have a user-specified discriminant -- but
that value is constant, so it doesn't need to be stored.

This change means that all newtype-like enums have the same size (and
layout) as their underlying type, which might be a useful property to
have, at least in terms of making programs' low-level behavior less
surprising.

Fix for issue #4830.

It seems to me the library needs more work to be done, but having a non-compilable sample program seems like bad news.

A simple fix for issue 2174.

Simple removal of rust_compare_and_swap_ptr from rt, as per Issue #4836

...ear

values to be copied.  Rewrite kind computation so that instead of directly
computing the kind it computes what kinds of values are present in the type,
and then derive kinds based on that. I find this easier to think about.

Fixes #4821.

r? @catamorphism

The function that formats and prints the squigly line that hilights
errors counted tabs as spaces, which resulted in incorrect error
messages when tabs were used for indentation. This change compares
the highlight line with the previous line and inserts a tab instead
of a space whenever such a tab exists on the previous line. Note
that error messages will still highlight incorrectly when the
previous line include characters that require more than one utf8
code point, as mentioned in issue 3260.

cc #4846

r? @pcwalton

Fixes #3169 and uses that to fix const array indexing, which I broke (in a way that doesn't break tests but will greatly confuse users) while trying to fix const enum vectors.

There was a simple typo on recursive in doc/tutorial-macros.md: s/recusive/recursive.

values to be copied.  Rewrite kind computation so that instead of directly
computing the kind it computes what kinds of values are present in the type,
and then derive kinds based on that. I find this easier to think about.

Fixes #4821.

cc #4846

The number of operands of the LLVM node initializing the array
underlying a const vector isn't always the array length -- if the
array is of a sufficiently primitive type and all the elements' values
are known (or something like that), LLVM uses a specialized Constant
subclass that stores the data packed, and thus has no operands.  Oops.

But, because llsize_of now gives us a ConstantInt, we can just fix
mozilla/rust#3169 and this all goes away.

Fix for #1531

That will, sadly, require one more snapshot.

This adds a `BaseIter` impl to `PriorityQueue`, `TreeMap`, `LinearMap` and `SmallIntMap`, and introduces a `ReverseIter` trait + implementations for `TreeMap`, `TreeSet` and `SmallIntMap`.

Converted --static, --gc, --jit, -g and --xg to -Z flags.

There were a bunch of problems with consts where an enum was contained within some other type (vector, tuple, struct, etc.); some of these would cause LLVM assertion failures, and some would silently read from the wrong address.  These changes should fix all of that.

It would be good if someone with access to a win32 host could do the equivalent of `make check-stageN-rpass TESTNAME=enum` on that platform before merging this.