add `-C overflow-checks` option
In addition to defining and handling the new option, we also add a method on librustc::Session for determining the necessity of overflow checks. This method provides a single point to sort out the three (!) different ways for turning on overflow checks: -C debug-assertions, -C overflow-checks, and -Z force-overflow-checks.
I was seeing a [run-pass/issue-28950.rs](b1363a73ed/src/test/run-pass/issue-28950.rs) failure on my machine with these patches, but I was also seeing the failure without the changes to the core compiler. We'll see what travis says.
Fixes#33134. r? @alexcrichton
In addition to defining and handling the new option, we also add a
method on librustc::Session for determining the necessity of overflow
checks. This method provides a single point to sort out the three (!)
different ways for turning on overflow checks: -C debug-assertions, -C
overflow-checks, and -Z force-overflow-checks.
Fixes#33134.
[MIR] SwitchInt Everywhere
Something I've been meaning to do for a very long while. This PR essentially gets rid of 3 kinds of conditional branching and only keeps the most general one - `SwitchInt`. Primary benefits are such that dealing with MIR now does not involve dealing with 3 different ways to do conditional control flow. On the other hand, constructing a `SwitchInt` currently requires more code than what previously was necessary to build an equivalent `If` terminator. Something trivially "fixable" with some constructor methods somewhere (MIR needs stuff like that badly in general).
Some timings (tl;dr: slightly faster^1 (unexpected), but also uses slightly more memory at peak (expected)):
^1: Not sure if the speed benefits are because of LLVM liking the generated code better or the compiler itself getting compiled better. Either way, its a net benefit. The CORE and SYNTAX timings done for compilation without optimisation.
```
AFTER:
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 31.50 secs
Finished release [optimized] target(s) in 31.42 secs
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 439.56 secs
Finished release [optimized] target(s) in 435.15 secs
CORE: 99% (24.81 real, 0.13 kernel, 24.57 user); 358536k resident
CORE: 99% (24.56 real, 0.15 kernel, 24.36 user); 359168k resident
SYNTAX: 99% (49.98 real, 0.48 kernel, 49.42 user); 653416k resident
SYNTAX: 99% (50.07 real, 0.58 kernel, 49.43 user); 653604k resident
BEFORE:
Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 31.84 secs
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 451.17 secs
CORE: 99% (24.66 real, 0.20 kernel, 24.38 user); 351096k resident
CORE: 99% (24.36 real, 0.17 kernel, 24.18 user); 352284k resident
SYNTAX: 99% (52.24 real, 0.56 kernel, 51.66 user); 645544k resident
SYNTAX: 99% (51.55 real, 0.48 kernel, 50.99 user); 646428k resident
```
cc @nikomatsakis @eddyb
This removes another special case of Switch by replacing it with the more general SwitchInt. While
this is more clunky currently, there’s no reason we can’t make it nice (and efficient) to use.
Add warning for () to ! switch
With feature(never_type) enabled diverging type variables will default to `!` instead of `()`. This can cause breakages where a trait is resolved on such a type.
This PR emits a future-compatibility warning when it sees this happen.
Miscellaneous refactors around how lints and typeck interact
This is preparation for making incr. comp. skip typeck. The main gist of is trying to rationalize the outputs from typeck that are not part of tables:
- one bit of output is the `used_trait_imports` set, which becomes something we track for dependencies
- the other big of output are various lints; we used to store these into a table on sess, but this work stores them into the`TypeckTables`, and then makes the lint pass consult that
- I think it probably makes sense to handle errors similarly, eventually, but that's not necessary now
r? @eddyb
Fixes#39495
This commit updates the version number to 1.17.0 as we're not on that version of
the nightly compiler, and at the same time this updates src/stage0.txt to
bootstrap from freshly minted beta compiler and beta Cargo.
Remove the workaround for gh32959
This workaround is no longer necessary as Rust, and by extension MIR, now support uninhabited type
properly. This removes the workaround for the gh32959 that was introduced in gh33267.
Fixes#32959
This workaround is no longer necessary as Rust, and by extension MIR, now support uninhabited type
properly. This removes the workaround for the gh32959 that was introduced in gh33267.
Fixes#32959
Avoid ICE when pretty-printing non-local MIR item.
This comes up when using `-Zunstable-options --unpretty=mir`. Previously, rustc would ICE due to an unwrap later in this function (after `as_local_node_id`). Instead, we should just ignore items from other crates when pretty-printing MIR.
This was reported in #rust: [this playground code](https://is.gd/PSMBZS) causes an ICE if you click the MIR button. The problem is the mention of the non-local item `std::usize::MAX`, so you can reduce the test case [a lot](https://is.gd/SaLjaa).
r? @eddyb
Hide uninhabitedness checks behind feature gate
This reverts the fix to match exhaustiveness checking so that it can be discussed. The new code is now hidden behind the `never_type` feature gate.
This comes up when using `-Zunstable-options --unpretty=mir`.
Previously, rustc would ICE due to an unwrap later in this function
(after `as_local_node_id`). Instead, we should just ignore items from
other crates when pretty-printing MIR.
exclusive range patterns
adds `..` patterns to the language under a feature gate (`exclusive_range_pattern`).
This allows turning
``` rust
match i {
0...9 => {},
10...19 => {},
20...29 => {},
_ => {}
}
```
into
``` rust
match i {
0..10 => {},
10..20 => {},
20..30 => {},
_ => {}
}
```
we can't create the target block until *after* we promote the arguments
- otherwise the arguments will be promoted into the target block. oops.
Fixes#38985.
Allow projections to be promoted to constants in MIR.
This employs the `LvalueContext` additions by @pcwalton to properly extend the MIR promotion of temporaries to allow projections (field accesses, indexing and dereferences) on said temporaries.
It's needed both parity with the old constant qualification logic (for current borrowck) and it fixes#38074.
The former is *required for soundness* if we accept the RFC for promoting rvalues to `'static` constants.
That is, until we get MIR borrowck and the same source of truth will be used for both checks and codegen.
[11/n] Separate ty::Tables into one per each body.
_This is part of a series ([prev](https://github.com/rust-lang/rust/pull/38449) | [next]()) 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>
In order to track the results of type-checking and inference for incremental recompilation, they must be stored separately for each function or constant value, instead of lumped together.
These side-`Tables` also have to be tracked by various passes, as they visit through bodies (all of which have `Tables`, even if closures share the ones from their parent functions). This is usually done by switching a `tables` field in an override of `visit_nested_body` before recursing through `visit_body`, to the relevant one and then restoring it - however, in many cases the nesting is unnecessary and creating the visitor for each body in the crate and then visiting that body, would be a much cleaner solution.
To simplify handling of inlined HIR & its side-tables, their `NodeId` remapping and entries HIR map were fully stripped out, which means that `NodeId`s from inlined HIR must not be used where a local `NodeId` is expected. It might be possible to make the nodes (`Expr`, `Block`, `Pat`, etc.) that only show up within a `Body` have IDs that are scoped to that `Body`, which would also allow `Tables` to use `Vec`s.
That last part also fixes#38790 which was accidentally introduced in a previous refactor.
Remove not(stage0) from deny(warnings)
Historically this was done to accommodate bugs in lints, but there hasn't been a
bug in a lint since this feature was added which the warnings affected. Let's
completely purge warnings from all our stages by denying warnings in all stages.
This will also assist in tracking down `stage0` code to be removed whenever
we're updating the bootstrap compiler.
fix promotion of MIR terminators
promotion of MIR terminators used to try to promote the destination it
is trying to promote, leading to stack overflow.
Also clean up the code in `promote_temp` a bit to make it more understandable.
Fixes#37991.
cc @nikomatsakis
r? @eddyb
