This commit marks as `#[stable]`:
* The `Index` and `IndexMut` traits. These are stabilized as taking the
index itself *by reference*; after extensive discussion it was
determined that this is a better match with our choices
elsewhere (e.g. making comparison operators auto-reference), and that
the use cases for by-value indices are better handled through
`IndexSet`.
* The `Range`, `RangeFrom` and `RangeTo` structs, introduced for range
notation.
* Various impls of `Index` and `IndexMut`.
The `FullRange` struct is left unstable as we may wish to rename it to
`RangeFull` in the future.
This commit also *removes* the `Step` trait in favor of direct
implementation of iterator traits on ranges for integers. The `Step`
trait was not a terribly useful factoring internally, and it is likely
that external integer types are best off implementing range iterators
directly. It was removed to simplify the API surface. We can always
reintroduce `Step` later if it turns out to be useful.
Due to this removal, this is a:
[breaking-change]
There's only one build-critical path in which perl is used, and it was to do a text replacement trivially achievable with sed(1).
I ported the indenter script because it [appears to be used][indenter], but removed check links because it appears to be entirely out of date.
[indenter]: https://github.com/rust-lang/rust/blob/master/src/librustc/util/common.rs#L60-70
So far, the source location an LLVM instruction was linked to was controlled by
`debuginfo::set_source_location()` and `debuginfo::clear_source_location()`.
This interface mimicked how LLVM's `IRBuilder` handles debug location
assignment. While this interface has some theoretical performance benefits, it
also makes things terribly unstable: One sets some quasi-global state and then
hopes that it is still correct when a given instruction is emitted---an
assumption that has been proven to not hold a bit too often.
This patch requires the debug source location to be passed to the actual
instruction emitting function. This makes source location assignment explicit
and will prevent future changes to `trans` from accidentally breaking things in
the majority of cases.
This patch does not yet implement the new principle for all instruction kinds
but the stepping experience should have improved significantly nonetheless
already.
As discussed with @aturon I added implementations of various op traits for references to built-in types which was already suggested by the ops reform RFC.
The 2nd commit updates the module documentation of core::ops to fully reflect the recent change from pass-by-reference to pass-by-value and expands on the implications for generic code.
This commit is an implementation of [RFC 565][rfc] which is a stabilization of
the `std::fmt` module and the implementations of various formatting traits.
Specifically, the following changes were performed:
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0565-show-string-guidelines.md
* The `Show` trait is now deprecated, it was renamed to `Debug`
* The `String` trait is now deprecated, it was renamed to `Display`
* Many `Debug` and `Display` implementations were audited in accordance with the
RFC and audited implementations now have the `#[stable]` attribute
* Integers and floats no longer print a suffix
* Smart pointers no longer print details that they are a smart pointer
* Paths with `Debug` are now quoted and escape characters
* The `unwrap` methods on `Result` now require `Display` instead of `Debug`
* The `Error` trait no longer has a `detail` method and now requires that
`Display` must be implemented. With the loss of `String`, this has moved into
libcore.
* `impl<E: Error> FromError<E> for Box<Error>` now exists
* `derive(Show)` has been renamed to `derive(Debug)`. This is not currently
warned about due to warnings being emitted on stage1+
While backwards compatibility is attempted to be maintained with a blanket
implementation of `Display` for the old `String` trait (and the same for
`Show`/`Debug`) this is still a breaking change due to primitives no longer
implementing `String` as well as modifications such as `unwrap` and the `Error`
trait. Most code is fairly straightforward to update with a rename or tweaks of
method calls.
[breaking-change]
Closes#21436
Removed use of unused LDPATH variable on Windows as is done for other platforms, and added GCC flag to ensure MINGW's ANSI compatible STDIO functions are used wherever available (required by jemalloc).
Without these changes it ends up setting the PATH twice, and the second time the PATH begins with `:` which is invalid. Also the regular msvcrt printf-like functions would be used which don't understand stuff like %hhd and %z which jemalloc uses.
This change ought not to make any difference to the output but it fixes the build process for me since at least my build environment couldn't handle that broken path caused by LDPATH being empty.
Compiling won't produce an executable just yet because (as stated in the next
paragraph) there are errors. By removing this sentance, the reader won't get
confused when they expect a successful compile i.e. if they don't read ahead one
paragraph, they are going to be checking their code and wondering why it's not
compiling.
