| Age | Commit message (Collapse) | Author | Lines |
|
Replaces the hack where a similar thing is done within trans.
|
|
|
|
|
|
fix pred_count accounting in SimplifyCfg
r? @eddyb
|
|
Address comments + Fix rebase
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This optimization kicks in a lot when bootstrapping the compiler.
|
|
Refactor away RBML from rustc_metadata.
RBML and `ty{en,de}code` have had their long-overdue purge. Summary of changes:
* Metadata is now a tree encoded in post-order and with relative backward references pointing to children nodes. With auto-deriving and type safety, this makes maintenance and adding new information to metadata painless and bug-free by default. It's also more compact and cache-friendly (cache misses should be proportional to the depth of the node being accessed, not the number of siblings as in EBML/RBML).
* Metadata sizes have been reduced, for `libcore` it went down 16% (`8.38MB` -> `7.05MB`) and for `libstd` 14% (`3.53MB` -> `3.03MB`), while encoding more or less the same information
* Specialization is used in the bundled `libserialize` (crates.io `rustc_serialize` remains unaffected) to customize the encoding (and more importantly, decoding) of various types, most notably those interned in the `TyCtxt`. Some of this abuses a soundness hole pending a fix (cc @aturon), but when that fix arrives, we'll move to macros 1.1 `#[derive]` and custom `TyCtxt`-aware serialization traits.
* Enumerating children of modules from other crates is now orthogonal to describing those items via `Def` - this is a step towards bridging crate-local HIR and cross-crate metadata
* `CrateNum` has been moved to `rustc` and both it and `NodeId` are now newtypes instead of `u32` aliases, for specializing their decoding. This is `[syntax-breaking]` (cc @Manishearth ).
cc @rust-lang/compiler
|
|
|
|
This only supports trivial cases in which there is exactly one def and
one use.
|
|
This is useful when passes want to remove statements without affecting
`Location`s.
|
|
This introduces a new `InstCombine` pass for us to place such peephole
optimizations.
|
|
|
|
|
|
Replace `_, _` with `..` in patterns
This is how https://github.com/rust-lang/rust/issues/33627 looks in action.
Looks especially nice in leftmost/rightmost positions `(first, ..)`/`(.., last)`.
I haven't touched libsyntax intentionally because the feature is still unstable.
|
|
Updated e0493 to new format (+ bonus).
Part of #35233.
Fixes #35999.
r? @jonathandturner
I'm not satisfied with the bonus part, there has to be an easier way to reach into the `Drop`'s span implementation. I'm all ears. :)
|
|
|
|
|
|
|
|
|
|
|
|
The warnings have already reached stable
The test rfc1592_deprecated is covered by `bad_sized` and
`unsized6`.
Fixes #33242
Fixes #33243
|
|
|
|
Rollup of 7 pull requests
- Successful merges: #35124, #35877, #35953, #36002, #36004, #36005, #36014
- Failed merges:
|
|
[MIR] track Location in MirVisitor, combine Location
All the users of MirVisitor::visit_statement implement their own statement index tracking. This PR move the tracking into MirVisitor itself.
Also, there were 2 separate implementations of Location that were identical. This PR eliminates one of them.
|
|
|
|
|
|
updated E0396 to new error format
Updated E0396 to new error format.
Part of #35233
Fixes #35779
Thanks again for letting me help!
r? @jonathandturner
|
|
updated E0395 to new error format
Updated E0395 to new error format.
Part of #35233
Fixes #35693
Thanks again for letting me help!
r? @jonathandturner
|
|
|
|
|
|
|
|
|
|
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`.
|