In preparation for [removing the `std::cmp::Ordering` reexport](https://github.com/rust-lang/rust/issues/19253), this needs to be done to prevent errors like:
```
note: in expansion of #[deriving]
note: expansion site
error: unresolved name `std::cmp::Equal`
#[deriving(Clone, PartialEq, PartialOrd, Eq, Ord, Show)]
^~~
```
On AArch64, libc::c_char is u8. There are some places in the code where i8 is assumed, which causes compilation errors.
(AArch64 is not officially supported yet, but this change does not hurt any other targets and makes the code future-proof.)
Build `clean::ConstantItem` values in the `inline` module and
pretty-print the AST for inlined const items.
Doc strings are still missing from inlined constants (see #19773).
Partially address #18156, #19722, #19185Fix#15821
r? @alexcrichton
This is a revival of #19517 (per request of @alexcrichton) now that the new snapshots have landed. We can now remove the last feature gates for if_let, while_let, and tuple_indexing scattered throughout the test sources since these features have been added to Rust.
Closes#19473.
Makes a couple changes that support the implementation of a REPL:
* Implementation of wrapper code for LLVM ExecutionEngine API
* Fixing a change I made earlier to reset compiler state in `phase_1_[...]`
instead of `compile_input` as the latter is not used in a REPL
This PR allows declaring traits and impls as `unsafe`. An `unsafe` trait requires an `unsafe` impl. An `unsafe` impl does not permit unsafe code within its interior (unless that code is contained within an unsafe block or unsafe fn, as normal). The commits are standalone.
r? @alexcrichton
cc #13231
They are replaced with unboxed closures.
cc @pcwalton @aturon
This is a [breaking-change]. Mostly, uses of `proc()` simply need to be converted to `move||` (unboxed closures), but in some cases the adaptations required are more complex (particularly for library authors). A detailed write-up can be found here: http://smallcultfollowing.com/babysteps/blog/2014/11/26/purging-proc/
The commits are ordered to emphasize the more important changes, but are not truly standalone.
Unlike a tuple variant constructor which can be called as a function, a struct variant constructor is not a function, so cannot be called.
If the user tries to assign the constructor to a variable, an ICE occurs, because there is no way to use it later. So we should stop the constructor from being used like that.
A similar mechanism already exists for a normal struct, as it prohibits a struct from being resolved. This commit does the same for a struct variant.
This commit also includes some changes to the existing tests.
Fixes#19452.