This update of compiler-rt includes rust-lang/compiler-rt#26 which provides a
targeted fix to the powisf2 intrinsics to keep #37559 fixed but also address
the new issue of #37630. I've also [written up my thoughts][1] on why it appears
that this is the correct fix for now (hoepfully at least).
Closes#37630
[1]: https://github.com/rust-lang/compiler-rt/pull/26#issuecomment-259751998
Without these changes, play.rust-lang.org (as of today) would wrap
our examples in `fn main() {}`. This prevents the user from being able
to easily run the tests.
macros: improve reexports
This PR
- avoids building multiple module graphs for a crate that is referenced by multiple `extern crate` items,
- registers `#[no_link] extern crate`s to avoid loading the same crate metadata twice,
- stability checks `#[no_link] extern crate`s,
- [breaking-chage]: `#[no_link] #[macro_use] extern crate syntax;` is allowed on stable today
- fixes `$crate` in `#[macro_reexport]`ed macros,
- [breaking-change] for `#[feature(macro_reexport)]` (technically)
- allows selective macro importing (i.e. `#[macro_use(foo, bar)]`) from custom derive crates, and
- refactors the crate metadata to support re-exported macros in arbitrary modules (not yet needed).
r? @nrc
This allows the initial build of src/bootstrap itself to use a local
cargo taken from `configure --local-rust-root`. It was already finding
rustc this way, but was always downloading cargo since it didn't know
where to find it.
It now matches the same logic that `config.rs` will use for stage0,
where both rustc and cargo are taken from `CFG_LOCAL_RUST_ROOT`.
Document the question mark operator in reference and the book's syntax index
The question mark operator will be stabilized for the Rust 1.13 release (unfortunately). Even though I don't like the operator, it still should be documented in the syntax index in the book and in the reference.
Maybe there are people who also want to change the book's chapters on error handling, depending on their views of what idiomatic error handling is, now that the operator is stable, but I don't want to and I'd prefer to keep this PR focused on the reference and syntax index only.
Please also apply this PR to the beta branch of rust.
[6/n] rustc: transition HIR function bodies from Block to Expr.
_This is part of a series ([prev](https://github.com/rust-lang/rust/pull/37408) | [next](https://github.com/rust-lang/rust/pull/37676)) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https://github.com/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well.
If any motivation is unclear, please ask for additional PR description clarifications or code comments._
<hr>
The main change here is that functions and closures both use `Expr` instead of `Block` for their bodies.
For closures this actually allows a honest representation of brace-less closure bodies, e.g. `|x| x + 1` is now distinguishable from `|x| { x + 1 }`, therefore this PR is `[syntax-breaking]` (cc @Manishearth).
Using `Expr` allows more logic to be shared between constant bodies and function bodies, with some small such changes already part of this PR, and eventually easing #35078 and per-body type tables.
Incidentally, there used to be some corners cut here and there and as such I had to (re)write divergence tracking for type-checking so that it is capable of understanding basic structured control-flow:
``` rust
fn a(x: bool) -> i32 {
// match also works (as long as all arms diverge)
if x { panic!("true") } else { return 1; }
0 // "unreachable expression" after this PR
}
```
And since liveness' "not all control paths return a value" moved to type-checking we can have nice things:
``` rust
// before & after:
fn b() -> i32 { 0; } // help: consider removing this semicolon
// only after this PR
fn c() -> i32 { { 0; } } // help: consider removing this semicolon
fn d() { let x: i32 = { 0; }; } // help: consider removing this semicolon
fn e() { f({ 0; }); } // help: consider removing this semicolon
```
[3/n] rustc: unify and simplify managing associated items.
_This is part of a series ([prev](https://github.com/rust-lang/rust/pull/37401) | [next](https://github.com/rust-lang/rust/pull/37404)) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https://github.com/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well.
If any motivation is unclear, please ask for additional PR description clarifications or code comments._
<hr>
`ImplOrTraitItem`/`impl_or_trait_item` have been renamed to `AssociatedItem`/`associated_item`.
The common fields from (what used to be) `ty::ImplOrTraitItem`'s variants have been pulled out, leaving only an `AssociatedKind` C-like enum to distinguish between methods, constants and types.
The type information has been removed from `AssociatedItem`, and as such the latter can now be computed on-demand from the local HIR map, i.e. an extern-crate-enabled `TraitItem | ImplItem`.
It may be moved to HIR in the future, if we intend to start using HIR types cross-crate.
`ty::ExplicitSelfCategory` has been moved to `rustc_typeck` and is produced on-demand from the signature of the method, and a `method_has_self_argument` field on `AssociatedItem`, which is used to indicate that the first argument is a sugary "method receiver" and as such, method call syntax can be used.
For the following code:
```rustc
struct Bar;
struct Bar;
fn main () {
}
```
show
```nocode
error[E0428]: a type named `Bar` has already been defined in this module
--> src/test/compile-fail/E0428.rs:12:1
|
11 | struct Bar;
| ----------- previous definition of `Bar` here
12 | struct Bar;
| ^^^^^^^^^^^
error: aborting due to previous error
```
instead of
```nocode
error[E0428]: a type named `Bar` has already been defined in this module
--> src/test/compile-fail/E0428.rs:12:1
|
11 | struct Bar;
| ----------- previous definition of `Bar` here
12 | struct Bar;
| ^^^^^^^^^^^
error[E0428]: a value named `Bar` has already been defined in this module
--> src/test/compile-fail/E0428.rs:12:1
|
11 | struct Bar;
| ----------- previous definition of `Bar` here
12 | struct Bar;
| ^^^^^^^^^^^
error: aborting due to 2 previous errors
```
_match: correct max_slice_length logic
The logic used to be wildly wrong, but before the HAIR patch its wrongness was in most cases hidden by another bug.
Fixes#37598.
r? @nikomatsakis
Marking the 'no-stack-check' codegen option as deprecated (Issue #34915)
Attempts to finish resolving issue #34915. Based on pull request #35156, which was closed due to inactivity.
