| Age | Commit message (Collapse) | Author | Lines |
|
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`.
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|