| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Implement the `!` type
This implements the never type (`!`) and hides it behind the feature gate `#[feature(never_type)]`. With the feature gate off, things should build as normal (although some error messages may be different). With the gate on, `!` is usable as a type and diverging type variables (ie. types that are unconstrained by anything in the code) will default to `!` instead of `()`.
|
|
|
|
Split Ty::is_empty method into is_never and is_uninhabited
|
|
Replace FnOutput with Ty
Replace FnConverging(ty) with ty
Purge FnDiverging, FunctionRetTy::NoReturn and FunctionRetTy::None
|
|
Parse -> ! as FnConverging(!)
Add AdjustEmptyToAny coercion to all ! expressions
Some fixes
|
|
[MIR] Add explicit SetDiscriminant StatementKind for deaggregating enums
cc #35186
To deaggregate enums, we need to be able to explicitly set the discriminant. This PR implements a new StatementKind that does that.
I think some of the places that have `panics!` now could maybe do something smarter.
|
|
|
|
Rollup of 23 pull requests
- Successful merges: #35279, #35331, #35358, #35375, #35445, #35448, #35482, #35486, #35505, #35528, #35530, #35532, #35536, #35537, #35541, #35552, #35554, #35555, #35557, #35562, #35565, #35569, #35576
- Failed merges: #35395, #35415, #35563
|
|
|
|
Update e0017 to new format
Updated `span_err!` to use `struct_span_err!` and provide a `span_label` that describes the error in context.
Updated the test to look for the `span_label`s that are provided now.
|
|
refactor lvalue_ty to be method of lvalue
Currently `Mir` (and `MirContext`) implement a method `lvalue_ty` (and actually many more `foo_ty`). But this should be a method of `Lvalue`.
If you have an `lvalue` and you want to get its type, the natural thing to write is:
```
lvalue.ty()
```
Of course it needs context, but still:
```
lvalue.ty(mir, tcx)
```
Makes more sense than
```
mir.lvalue_ty(lvalue, tcx)
```
I actually think we should go a step farther and have traits so we could get the type of some value generically, but that's up for debate. The thing I'm running into a lot in the compiler is I have a value of type `Foo` and I know that there is some related type `Bar` which I can get through some combination of method calls, but it's often not as direct as I would imagine. Unless you already know the code, its not clear why you would look in `Mir` for a method to get the type of an `Lvalue`.
|
|
Address ICEs running w/ incremental compilation and building glium
Fixes for various ICEs I encountered trying to build glium with incremental compilation enabled. Building glium now works. Of the 4 ICEs, I have test cases for 3 of them -- I didn't isolate a test for the last commit and kind of want to go do other things -- most notably, figuring out why incremental isn't saving much *effort*.
But if it seems worthwhile and I can come back and try to narrow down the problem.
r? @michaelwoerister
Fixes #34991
Fixes #32015
|
|
Per the discussion on #34765, we make one `DepNode::Mir` variant and use
it to represent both the MIR tracking map as well as passes that operate
on MIR. We also track loads of cached MIR (which naturally comes from
metadata).
Note that the "HAIR" pass adds a read of TypeckItemBody because it uses
a myriad of tables that are not individually tracked.
|
|
|
|
- Fix note message, fix tests.
|
|
For https://github.com/rust-lang/rust/issues/35194
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use it instead of a `panic` for inexhaustive matches and correct the
comment. I think we trust our match-generation algorithm enough to
generate these blocks, and not generating an `unreachable` means that
LLVM won't optimize `match void() {}` to an `unreachable`.
|
|
|
|
|
|
|
|
|
|
non-MIR translation is still not supported for these and will happily ICE.
This is a [breaking-change] for many uses of slice_patterns.
|
|
|
|
|
|
|
|
|
|
Add, Sub, Mul, Shl, and Shr are checked using a new Rvalue:
CheckedBinaryOp, while Div, Rem and Neg are handled with explicit checks
in the MIR.
|
|
the *only* place where critical edges need to be broken is on Call
instructions, so only break them there.
|
|
There weren't any in practice, but as these cause MSVC-only problems, the
check looks like a good idea.
|
|
this introduces a DropAndReplace terminator as a fix to #30380. That terminator
is suppsoed to be translated by desugaring during drop elaboration, which is
not implemented in this commit, so this breaks `-Z orbit` temporarily.
|
|
|
|
mir: always allow &mut [...] in static mut regardless of the array length.
|
|
[MIR] Enhance the SimplifyCfg pass to merge consecutive blocks
Updated from #30238, including the changes suggested by @Aatch.
|
|
Only break critical edges where actually needed
Currently, to prepare for MIR trans, we break _all_ critical edges,
although we only actually need to do this for edges originating from a
call that gets translated to an invoke instruction in LLVM.
This has the unfortunate effect of undoing a bunch of the things that
SimplifyCfg has done. A particularly bad case arises when you have a
C-like enum with N variants and a derived PartialEq implementation.
In that case, the match on the (&lhs, &rhs) tuple gets translated into
nested matches with N arms each and a basic block each, resulting in N²
basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks, but
breaking the critical edges means that we go back to N².
In nickel.rs, there is such an enum with roughly N=800. So we get about
640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to
reduce that to the final "disr_a == disr_b".
So before this patch, we had 2.5M lines of IR with 640K basic blocks,
which took about about 3.6s in LLVM to get optimized and translated.
After this patch, we get about 650K lines with about 1.6K basic blocks
and spent a little less than 0.2s in LLVM.
cc #33111
r? @Aatch
|
|
|
|
mir: don't attempt to promote Unpromotable constant temps.
Fixes #33537. This was a non-problem in regular functions, but we also promote in `const fn`s.
There we always qualify temps so you can't depend on `Unpromotable` temps being `NOT_CONST`.
|
|
|
|
Currently, to prepare for MIR trans, we break _all_ critical edges,
although we only actually need to do this for edges originating from a
call that gets translated to an invoke instruction in LLVM.
This has the unfortunate effect of undoing a bunch of the things that
SimplifyCfg has done. A particularly bad case arises when you have a
C-like enum with N variants and a derived PartialEq implementation.
In that case, the match on the (&lhs, &rhs) tuple gets translated into
nested matches with N arms each and a basic block each, resulting in N²
basic blocks. SimplifyCfg reduces that to roughly 2*N basic blocks, but
breaking the critical edges means that we go back to N².
In nickel.rs, there is such an enum with roughly N=800. So we get about
640K basic blocks or 2.5M lines of LLVM IR. LLVM takes a while to
reduce that to the final "disr_a == disr_b".
So before this patch, we had 2.5M lines of IR with 640K basic blocks,
which took about about 3.6s in LLVM to get optimized and translated.
After this patch, we get about 650K lines with about 1.6K basic blocks
and spent a little less than 0.2s in LLVM.
cc #33111
|
