| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
First issue here was the fact that we’d only allow negating integers in i64 range in case the
integer was not infered yes. While this is not the direct cause of the issue, its still good to fix
it.
The real issue here is the code handling specifically the `min_value` literals. While I128_OVERFLOW
has the expected value (0x8000_..._0000), match using this value as a pattern is handled
incorrectly by the stage1 compiler (it seems to be handled correctly, by the stage2 compiler). So
what we do here is extract this pattern into an explicit `==` until the next snapshot.
Fixes #38987
|
|
|
|
|
|
|
|
This commit introduces 128-bit integers. Stage 2 builds and produces a working compiler which
understands and supports 128-bit integers throughout.
The general strategy used is to have rustc_i128 module which provides aliases for iu128, equal to
iu64 in stage9 and iu128 later. Since nowhere in rustc we rely on large numbers being supported,
this strategy is good enough to get past the first bootstrap stages to end up with a fully working
128-bit capable compiler.
In order for this strategy to work, number of locations had to be changed to use associated
max_value/min_value instead of MAX/MIN constants as well as the min_value (or was it max_value?)
had to be changed to use xor instead of shift so both 64-bit and 128-bit based consteval works
(former not necessarily producing the right results in stage1).
This commit includes manual merge conflict resolution changes from a rebase by @est31.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
They don't implement FnLikeNode anymore, instead are handled differently
further up in the call tree. Also, keep less information (just def ids
for the args).
|
|
|
|
|
|
|
|
This is quite hacky and I hope to refactor it a bit, but at least it
seems to work.
|
|
|
|
|
|
|
|
This changes structures like this:
```
[ ExprArray | 8 | P ]
|
v
[ P | P | P | P | P | P | P | P ]
|
v
[ ExprTup | 2 | P ]
|
v
[ P | P ]
|
v
[ Expr ]
```
to this:
```
[ ExprArray | 8 | P ]
|
v
[ [ ExprTup | 2 | P ] | ... ]
|
v
[ Expr | Expr ]
```
|
|
places.
|
|
[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
```
|
|
|
|
|
|
Shrink `hir::Expr` slightly
r? @eddyb
|
|
Use DefId's in const eval for cross-crate const fn's
Fixes #36954.
r? @eddyb
cc @raphaelcohn
|
|
On 64-bit platforms this reduces the size of `Expr_` from 64 bytes to
56 bytes, and reduces the size of `Expr` from 88 bytes to 80 bytes.
|
|
|
|
|
|
NaN checking was a lint for a deprecated feature. It can go away.
|
|
|
|
|
|
|
|
|
|
Fix ICE test in compiletest fail-tests
While working on Clippy which uses *compiletest*, I noticed that as long as all expected error are found, *compile-fail* tests will be marked *ok* even if there is an ICE. One function seems to have not been updated with JSON errors because ICEs are now reported like this:
```json
{"message":"../src/librustc/ty/context.rs:161: Attempted to intern `_` which contains inference types/regions in the global type context","code":null,"level":"error: internal compiler error","spans":[],"children":[],"rendered":null}
```
I don't think I can add a test for that.
I guess:
r? @nikomatsakis
|
|
|
