Update array documentation for Clone trait changes
Just a note, for this to work, `T` doesn't have to `Copy`, `Clone` is sufficient. For instance, the following works.
```rust
fn x(a: &[String; 100]) -> [String; 100] {
a.clone()
}
```
ci: Update Travis OSX builders
Looks like Travis [has announced][blog] that our current `xcode8.2` image is
being deprecated and the recommended Xcode 7 image is `xcode7.3`. This updates
us to these ahead of time to make sure we can shake out any bugs, if any.
[blog]: https://blog.travis-ci.com/2017-10-16-a-new-default-os-x-image-is-coming
don't issue "expected statement after outer attr." after inner attr.
While an inner attribute here is in fact erroneous, that error ("inner
attribute is not permitted in this context") successfully gets set earlier;
this further admonition is nonsensical.
Resolves#45296.
Unfortunately, #45255 does not quite cut it,
so use a different approach to have Solaris 10 compatibility
by tricking libbacktrace's autoconf tests.
The sysroot download routine is slightly changed, too.
Add the test for #40003.
I checked that the test failed to compile on an older nightly (I tried 2017-09-29) and that it compiles against master.
Closes#40003.
core: derive Clone for result::IntoIter
It appears to be a simple oversight that `result::IntoIter<T>` doesn't
implement `Clone` (where `T: Clone`). We do already have `Clone` for
`result::Iter`, as well as the similar `option::IntoIter` and `Iter`.
Add more __future__ imports to increase compatibility with Python 3 in bootstrap
The functionality of the `__future__` imports are described [here](https://docs.python.org/3/library/__future__.html).
These will help ensure the bootstrap code stays compatible with Python 3. If changes are made in the future that use absolute imports, division, or the `print` function, this will be ensure that running it under Python 2 will pass or fail the same way as Python 3.
`Option` is made a [new-style class](https://docs.python.org/2/reference/datamodel.html#new-style-and-classic-classes), so that it behaves the same way in Python 2 and 3.
The `__future__ unicode_literals` import is not used, because that can change the semantics of the code in Python 2 in unwanted ways. For more information see [this article](http://python-future.org/unicode_literals.html).
The cache was broken anyhow and this computation doesn't look that
expensive. These public accessors could potentially become queries,
but we'd have to add some more complex logic around lift. I'd prefer
to have some test cases to profile with before doing that.
Fixes#44402.
