[12/12] On-demand type-checking, const-evaluation, MIR building & const-qualification. #40008

eddyb · 2017-02-21T18:31:06Z

This is the last of a series (prev) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. MIR-based 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.

As this contains all of the changes that didn't fit neatly into other PRs, I'll be elaborating a bit:

User-facing changes

when determining whether an impl Trait type implements an auto-trait (e.g. Send or Sync), the function the impl Trait came from has to be inferred and type-checking, disallowing cycles
- this results from not having an obvious place to put the "deferred obligation" in on-demand atm
- while we could model side-effects like that and "post-processing passes" better, it's still more limiting than being able to know the result in the original function (e.g. specialization) and there are serious problems around region-checking (if a Send impl required 'static, it wasn't enforced)
early const-eval requires type-checking and const-qualification to be performed first, which means:
- you get the intended errors before (if any) constant evaluation error that is simply fallout
- associated consts should always work now, and const fn type parameters are properly tracked
  - don't get too excited, array lengths still can't depend on type parameters
Tracking issue for 'Allow Self to appear in the where clause of trait impls' #38864 works as intended now, with Self being allowed in impl bounds
Remove phase separation between specialization graph construction and projection #32205 is largely improved, with associated types being limited to "exact match" impls (as opposed to traversing the specialization graph to resolve unspecified type parameters to their defaults in another impl or in the trait) while checking for overlaps building the specialization graph for that trait - once all the trait impls' have been checked for coherence (including ahead-of-time/on-demand), it's uniform
crater report looks clean (aside from clippy which broke due to rustc internal changes)

Compiler-internal changes

ty::Generics
- no longer contains the actual type parameter defaults, instead they're associated with the type parameter's DefId, like associated types in a trait definition
  - this allows computing ty::Generics as a leaf (reading only its own HIR)
- holds a mapping from DefIndex of type parameters to their indices
ty::AdtDef
- only tracks #[repr(simd)] in its ReprOptions repr field
- doesn't contain enum discriminant values, but instead each variant either refers to either an explicit value for its discriminant, or the distance from the last explicit discriminant, if any
  - the .discriminants(tcx) method produces an iterator of ConstInt values, looking up explicit discriminants in a separate map, if necessary
  - this allows computing ty::AdtDef as a leaf (reading only its own HIR)
Small note: the two above (Generics, AdtDef), TraitDef and AssociatedItem should probably end up as part of the HIR, eventually, as they're trivially constructed from it
ty::FnSig
- now also holds ABI and unsafety, alongside argument types, return type and C variadicity
- &ty::BareFnTy and ty::ClosureTy have been replaced with PolyFnSig = Binder<FnSig>
  - BareFnTy was interned and ClosureTy was treated as non-trivial to Clone because they had a PolyFnSig and so used to contain a Vec<Ty> (now &[Ty])
ty::maps
- all the DepTrackingMaps have been grouped in a structure available at tcx.maps
- when creating the tcx, a set of Providers (one fn pointer per map) is required for the local crate, and one for all other crates (i.e. metadata loading), librustc_driver plugging the various crates (e.g. librustc_metadata, librustc_typeck, librustc_mir) into it
- when a map is queried and the value is missing, the appropriate fn pointer from the Providers of that crate is called with the TyCtxt and the key being queried, to produce the value on-demand
rustc_const_eval
- demands both typeck_tables and mir_const_qualif (in preparation for miri)
- tracks Substs in ConstVal::Function for const fn calls
- returns TypeckError if type-checking has failed (or cases that can only be reached if it had)
  - this error kind is never reported, resulting in less noisy/redundant diagnostics
- fixes ICE in librustc_const_eval: bad ty_hint: TyBool, Int(1, Unsuffixed) #39548 (testcase by @larsluthman, taken from Fix type hint bug in eval_const_expr_partial() (issue #39548) #39812, which this supersedes)
on-demand has so far been hooked up to:
- rustc_metadata::cstore_impl: ty, generics, predicates, super_predicates, trait_def, adt_def, variances, associated_item_def_ids, associated_item, impl_trait_ref, custom_coerce_unsized_kind, mir, mir_const_qualif, typeck_tables, closure_kind, closure_type
- rustc_typeck::collect: ty, generics, predicates, super_predicates, type_param_predicates, trait_def, adt_def, impl_trait_ref
- rustc_typeck::coherence: coherent_trait, coherent_inherent_impls
- rustc_typeck::check: typeck_tables, closure_type, closure_kind
- rustc_mir::mir_map: mir
- rustc_mir::transform::qualify_consts: mir_const_qualif

rust-highfive · 2017-02-21T18:31:20Z

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

nikomatsakis

This looks amazing as usual. My concern is mainly about the dependency graph management. The handling here is definitely dubious, but maybe we want to address it in follow-up PRs.

nikomatsakis · 2017-02-22T18:23:24Z

src/librustc/infer/mod.rs

-        let default = def.default.map(|default| {
-            type_variable::Default {
+        let default = if def.has_default {
+            let default = self.tcx.item_type(def.def_id);


Man, we really need to document all the things that can have def-ids and what each table means for each kind of thing. Is this written down anywhere? I guess not.

nikomatsakis · 2017-02-22T18:27:49Z

src/librustc_resolve/lib.rs

@@ -718,6 +754,11 @@ enum RibKind<'a> {

    // We passed through a `macro_rules!` statement with the given expansion
    MacroDefinition(Mark),
+
+    // All bindings in this rib aretype parameters that can't be used


Nit: s/aretype/are type/

nikomatsakis · 2017-02-22T18:30:02Z

src/test/compile-fail/issue-18183.rs

-pub struct Foo<Bar=Bar>; //~ ERROR E0128
-                         //~| NOTE defaulted type parameters cannot be forward declared
+pub struct Foo<Bar=Bar>(Bar); //~ ERROR E0128
+                              //~| NOTE defaulted type parameters cannot be forward declared


Is there a test demonstrating that bounds can reference "future" type parameters? e.g., fn foo<T: Foo<U>, U>() { ... }? It seemed to me that your resolve changes were intending to keep this working...

nikomatsakis · 2017-02-22T20:30:00Z

src/librustc/ty/maps.rs

+    }
+}
+
+impl<'tcx, T: Default> Value<'tcx> for T {


I'm not sure how I feel about this. Reporting "some random but otherwise valid" value when an error occurs seems likely to lead to downstream errors that don't make any sense. For example, if the result is Vec<Predicate>, and we return vec![], then we'll generate a bunch of errors that are based on the fact that we see no predicates. If we returned instead Result<Vec<Predicate>, ErrorReported>, we would know that we can suppress errors in the downstream work.

Regardless having a blanket impl for all T: Default seems like it will do surprising things.

nikomatsakis · 2017-02-22T20:44:04Z

src/librustc/ty/mod.rs

-    pub fn destructor(&self) -> Option<DefId> {
-        self.destructor.get()
+    pub fn destructor(&self, tcx: TyCtxt<'a, 'gcx, 'tcx>) -> Option<DefId> {
+        if self.flags.get().intersects(AdtFlags::IS_DTOR_VALID) {


This seems like it will create incorrect dependencies in the dep-graph. The destructor field is shared mutable state -- it needs to be tracked. Consider this:

TASK A: calls foo.destructor(). As this is the first call, it will create read edges to TASK A, then update the destructor cache.

TASK B: calls foo.destructor() -- cache is populated, no read edges result.

This is pre-existing though. The correct solution IMO is to query the trait system but fixing all the users is a bit tricky.

ah, it's pre-existing? ok, I guess we can live with it then. I thought I closed up the cells in there, but I guess not.

nikomatsakis · 2017-02-22T20:57:30Z

src/librustc/ty/trait_def.rs

@@ -155,6 +164,13 @@ impl<'a, 'gcx, 'tcx> TraitDef {
        assert!(impl_def_id.is_local());
        let was_new = self.record_impl(tcx, impl_def_id, impl_trait_ref);
        assert!(was_new);
+
+        self.local_impl_count.set(self.local_impl_count.get() + 1);


This is also shared mutable state ... as are a number of other fields in the TraitDef etc ... I'm not sure whether it will cause problems here. The hack ignoring edges for force may... be ok... at least for now. I was figuring I would take a stab at cleaning up that stuff once this PR lands...

nikomatsakis · 2017-02-22T21:42:41Z

src/librustc_mir/transform/qualify_consts.rs

+                    tcx: TyCtxt<'a, 'tcx, 'tcx>,
+                    hooks: &mut [Box<for<'s> MirPassHook<'s>>])
+    {
+        let def_ids = tcx.maps.mir.borrow().keys();


it is pretty dubious to iterate over keys -- seems like we should talk over this -- but it may make sense to land the PR and then do a follow-up

Yeah things like this should probably be switched to iterate over bodies instead.

nikomatsakis · 2017-02-23T19:56:58Z

@eddyb you seen the travis failures?

eddyb · 2017-02-23T20:03:41Z

Yeah, I've been meaning to fix them - they're just diagnostics changes in UI tests.

nikomatsakis · 2017-02-23T20:44:33Z

@eddyb ok, so to summarize what we said on IRC (and "for the record"):

The wacky dep-graph stuff is pre-existing, I'll try to prioritize fixing it.
The Default trait seems me as risky, but for now we'll bias towards "keep going with compilation, even if you get weird derived errors". We can either patch problems one by one, or try to remove the Default trait impl and then make the default cases abort if we don't have a good recovery for them.

So -- yeah, r=me, let's just land this thing already.

eddyb · 2017-02-24T07:25:56Z

@bors r=nikomatsakis

bors · 2017-02-24T07:25:57Z

📌 Commit 97d84c8 has been approved by nikomatsakis

eddyb · 2017-02-25T09:44:25Z

@bors r=nikomatsakis

bors · 2017-02-25T09:44:25Z

📌 Commit 002a449 has been approved by nikomatsakis

Rollup of 28 pull requests - Successful merges: #39859, #39864, #39888, #39903, #39905, #39914, #39945, #39950, #39953, #39961, #39980, #39988, #39993, #39995, #40019, #40020, #40022, #40024, #40025, #40026, #40027, #40031, #40035, #40037, #40038, #40064, #40069, #40086 - Failed merges: #39927, #40008, #40047

bors · 2017-02-25T15:03:09Z

☔ The latest upstream changes (presumably #40091) made this pull request unmergeable. Please resolve the merge conflicts.

eddyb · 2017-02-25T15:07:31Z

Note to self: never use the GitHub conflict resolution UI, it makes merge commits.

frewsxcv · 2017-02-25T21:47:11Z

@bors p=20

bors · 2017-02-26T00:32:22Z

💔 Test failed - status-travis

eddyb · 2017-02-26T00:55:38Z

Welp, it was me: I compared the log with a previous build and it went from 2:22:27 to 2:51:53.
Worst of it AFAICT is compile-fail: 201.065 seconds to 661.318 seconds.

eddyb · 2017-02-26T07:15:40Z

I can't reproduce a slowdown locally, so I'm still confused.

EDIT: No wonder, x86_64-unknown-linux-gnu on Travis only differs by 17 seconds...

eddyb · 2017-02-26T08:00:00Z

@bors retry

it must be spurious, riiight?

bors · 2017-02-26T08:07:10Z

⌛ Testing commit d9f0a94 with merge 67a5171...

@larsluthman

[12/12] On-demand type-checking, const-evaluation, MIR building & const-qualification. _This is the last of a series ([prev](#38813)) 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> As this contains all of the changes that didn't fit neatly into other PRs, I'll be elaborating a bit: ### User-facing changes * when determining whether an `impl Trait` type implements an auto-trait (e.g. `Send` or `Sync`), the function the `impl Trait` came from has to be inferred and type-checking, disallowing cycles * this results from not having an obvious place to put the "deferred obligation" in on-demand atm * while we could model side-effects like that and "post-processing passes" better, it's still more limiting than being able to know the result in the original function (e.g. specialization) *and* there are serious problems around region-checking (if a `Send` impl required `'static`, it wasn't enforced) * early const-eval requires type-checking and const-qualification to be performed first, which means: * you get the intended errors before (if any) constant evaluation error that is simply fallout * associated consts should always work now, and `const fn` type parameters are properly tracked * don't get too excited, array lengths still can't depend on type parameters * #38864 works as intended now, with `Self` being allowed in `impl` bounds * #32205 is largely improved, with associated types being limited to "exact match" `impl`s (as opposed to traversing the specialization graph to resolve unspecified type parameters to their defaults in another `impl` or in the `trait`) *while* checking for overlaps building the specialization graph for that trait - once all the trait impls' have been checked for coherence (including ahead-of-time/on-demand), it's uniform * [crater report](https://gist.github.com/eddyb/bbb869072468c7e08d6d808e75938051) looks clean (aside from `clippy` which broke due to `rustc` internal changes) ### Compiler-internal changes * `ty::Generics` * no longer contains the actual type parameter defaults, instead they're associated with the type parameter's `DefId`, like associated types in a trait definition * this allows computing `ty::Generics` as a leaf (reading only its own HIR) * holds a mapping from `DefIndex` of type parameters to their indices * `ty::AdtDef` * only tracks `#[repr(simd)]` in its `ReprOptions` `repr` field * doesn't contain `enum` discriminant values, but instead each variant either refers to either an explicit value for its discriminant, or the distance from the last explicit discriminant, if any * the `.discriminants(tcx)` method produces an iterator of `ConstInt` values, looking up explicit discriminants in a separate map, if necessary * this allows computing `ty::AdtDef` as a leaf (reading only its own HIR) * Small note: the two above (`Generics`, `AdtDef`), `TraitDef` and `AssociatedItem` should probably end up as part of the HIR, eventually, as they're trivially constructed from it * `ty::FnSig` * now also holds ABI and unsafety, alongside argument types, return type and C variadicity * `&ty::BareFnTy` and `ty::ClosureTy` have been replaced with `PolyFnSig = Binder<FnSig>` * `BareFnTy` was interned and `ClosureTy` was treated as non-trivial to `Clone` because they had a `PolyFnSig` and so used to contain a `Vec<Ty>` (now `&[Ty]`) * `ty::maps` * all the `DepTrackingMap`s have been grouped in a structure available at `tcx.maps` * when creating the `tcx`, a set of `Providers` (one `fn` pointer per map) is required for the local crate, and one for all other crates (i.e. metadata loading), `librustc_driver` plugging the various crates (e.g. `librustc_metadata`, `librustc_typeck`, `librustc_mir`) into it * when a map is queried and the value is missing, the appropriate `fn` pointer from the `Providers` of that crate is called with the `TyCtxt` and the key being queried, to produce the value on-demand * `rustc_const_eval` * demands both `typeck_tables` and `mir_const_qualif` (in preparation for miri) * tracks `Substs` in `ConstVal::Function` for `const fn` calls * returns `TypeckError` if type-checking has failed (or cases that can only be reached if it had) * this error kind is never reported, resulting in less noisy/redundant diagnostics * fixes #39548 (testcase by @larsluthman, taken from #39812, which this supersedes) * on-demand has so far been hooked up to: * `rustc_metadata::cstore_impl`: `ty`, `generics`, `predicates`, `super_predicates`, `trait_def`, `adt_def`, `variances`, `associated_item_def_ids`, `associated_item`, `impl_trait_ref`, `custom_coerce_unsized_kind`, `mir`, `mir_const_qualif`, `typeck_tables`, `closure_kind`, `closure_type` * `rustc_typeck::collect`: `ty`, `generics`, `predicates`, `super_predicates`, `type_param_predicates`, `trait_def`, `adt_def`, `impl_trait_ref` * `rustc_typeck::coherence`: `coherent_trait`, `coherent_inherent_impls` * `rustc_typeck::check`: `typeck_tables`, `closure_type`, `closure_kind` * `rustc_mir::mir_map`: `mir` * `rustc_mir::transform::qualify_consts`: `mir_const_qualif`

bors · 2017-02-26T11:07:17Z

💔 Test failed - status-travis

eddyb · 2017-02-27T12:20:53Z

FWIW, investigation is ongoing in #40114.

EDIT: Suspect found: -Zsave-analysis-api doubles the size of metadata in libraries.
It creates a ton of filemaps, attempting to fix that to see if it fixes my own problem.

eddyb · 2017-02-28T06:40:29Z

@bors r=nikomatsakis

Indeed, it appears those filemaps were adding 3MB to libstd's 3.5MB - that's a lot of them!

As to what this PR does differently: when doing any request without an explicit Span (so all of the tcx methods, e.g. tcx.item_generics(def_id), tcx.item_type(def_id), etc.), the Span of the DefId was being computed for the "on-demand cycle-check stack", which would also happen for cross-crate DefIds.

Now, that may seem expensive, but it's empirically unmeasurable (except maybe this PR would speed other things up so what I'm seeing is speedup + slowdown => neutral), unless those cross-crate Spans require reading all the cross-crate filemaps and there were a lot of them (from save-analysis).

bors · 2017-02-28T06:40:30Z

📌 Commit f702b20 has been approved by nikomatsakis

bors · 2017-02-28T07:59:30Z

⌛ Testing commit f702b20 with merge e1cb9ba...

@larsluthman

[12/12] On-demand type-checking, const-evaluation, MIR building & const-qualification. _This is the last of a series ([prev](#38813)) 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> As this contains all of the changes that didn't fit neatly into other PRs, I'll be elaborating a bit: ### User-facing changes * when determining whether an `impl Trait` type implements an auto-trait (e.g. `Send` or `Sync`), the function the `impl Trait` came from has to be inferred and type-checking, disallowing cycles * this results from not having an obvious place to put the "deferred obligation" in on-demand atm * while we could model side-effects like that and "post-processing passes" better, it's still more limiting than being able to know the result in the original function (e.g. specialization) *and* there are serious problems around region-checking (if a `Send` impl required `'static`, it wasn't enforced) * early const-eval requires type-checking and const-qualification to be performed first, which means: * you get the intended errors before (if any) constant evaluation error that is simply fallout * associated consts should always work now, and `const fn` type parameters are properly tracked * don't get too excited, array lengths still can't depend on type parameters * #38864 works as intended now, with `Self` being allowed in `impl` bounds * #32205 is largely improved, with associated types being limited to "exact match" `impl`s (as opposed to traversing the specialization graph to resolve unspecified type parameters to their defaults in another `impl` or in the `trait`) *while* checking for overlaps building the specialization graph for that trait - once all the trait impls' have been checked for coherence (including ahead-of-time/on-demand), it's uniform * [crater report](https://gist.github.com/eddyb/bbb869072468c7e08d6d808e75938051) looks clean (aside from `clippy` which broke due to `rustc` internal changes) ### Compiler-internal changes * `ty::Generics` * no longer contains the actual type parameter defaults, instead they're associated with the type parameter's `DefId`, like associated types in a trait definition * this allows computing `ty::Generics` as a leaf (reading only its own HIR) * holds a mapping from `DefIndex` of type parameters to their indices * `ty::AdtDef` * only tracks `#[repr(simd)]` in its `ReprOptions` `repr` field * doesn't contain `enum` discriminant values, but instead each variant either refers to either an explicit value for its discriminant, or the distance from the last explicit discriminant, if any * the `.discriminants(tcx)` method produces an iterator of `ConstInt` values, looking up explicit discriminants in a separate map, if necessary * this allows computing `ty::AdtDef` as a leaf (reading only its own HIR) * Small note: the two above (`Generics`, `AdtDef`), `TraitDef` and `AssociatedItem` should probably end up as part of the HIR, eventually, as they're trivially constructed from it * `ty::FnSig` * now also holds ABI and unsafety, alongside argument types, return type and C variadicity * `&ty::BareFnTy` and `ty::ClosureTy` have been replaced with `PolyFnSig = Binder<FnSig>` * `BareFnTy` was interned and `ClosureTy` was treated as non-trivial to `Clone` because they had a `PolyFnSig` and so used to contain a `Vec<Ty>` (now `&[Ty]`) * `ty::maps` * all the `DepTrackingMap`s have been grouped in a structure available at `tcx.maps` * when creating the `tcx`, a set of `Providers` (one `fn` pointer per map) is required for the local crate, and one for all other crates (i.e. metadata loading), `librustc_driver` plugging the various crates (e.g. `librustc_metadata`, `librustc_typeck`, `librustc_mir`) into it * when a map is queried and the value is missing, the appropriate `fn` pointer from the `Providers` of that crate is called with the `TyCtxt` and the key being queried, to produce the value on-demand * `rustc_const_eval` * demands both `typeck_tables` and `mir_const_qualif` (in preparation for miri) * tracks `Substs` in `ConstVal::Function` for `const fn` calls * returns `TypeckError` if type-checking has failed (or cases that can only be reached if it had) * this error kind is never reported, resulting in less noisy/redundant diagnostics * fixes #39548 (testcase by @larsluthman, taken from #39812, which this supersedes) * on-demand has so far been hooked up to: * `rustc_metadata::cstore_impl`: `ty`, `generics`, `predicates`, `super_predicates`, `trait_def`, `adt_def`, `variances`, `associated_item_def_ids`, `associated_item`, `impl_trait_ref`, `custom_coerce_unsized_kind`, `mir`, `mir_const_qualif`, `typeck_tables`, `closure_kind`, `closure_type` * `rustc_typeck::collect`: `ty`, `generics`, `predicates`, `super_predicates`, `type_param_predicates`, `trait_def`, `adt_def`, `impl_trait_ref` * `rustc_typeck::coherence`: `coherent_trait`, `coherent_inherent_impls` * `rustc_typeck::check`: `typeck_tables`, `closure_type`, `closure_kind` * `rustc_mir::mir_map`: `mir` * `rustc_mir::transform::qualify_consts`: `mir_const_qualif`

bors · 2017-02-28T10:00:23Z

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing e1cb9ba to master...

Don't duplicate the extern providers once for each crate This should give a small perf improvement for small crates by avoiding a memcpy of a pretty big struct for each loaded crate. In addition would be useful for replacing the sequential `CrateNum` everywhere with the hash based `StableCrateId` introduced in rust-lang#81635, which would allow avoiding remapping of `CrateNum`'s when loading crate metadata. While this PR is not strictly needed for that, it is necessary to prevent a performance loss due to it. I think this duplication was done in rust-lang#40008 (which introduced the query system) to make it possible to compile multiple crates in a single session in the future. I think this is unlikely to be implemented any time soon. In addition this PR can easily be reverted if necessary to implement this.

rust-highfive assigned nikomatsakis Feb 21, 2017

This was referenced Feb 21, 2017

[11/n] Separate ty::Tables into one per each body. #38813

Merged

RFC: Extend and stabilize the FixedSizeArray trait rust-lang/rfcs#1915

Closed

burdges mentioned this pull request Feb 22, 2017

Shake output should be variable length RustCrypto/hashes#14

Closed

nikomatsakis requested changes Feb 22, 2017

View reviewed changes

eddyb force-pushed the lazy-12 branch from 1a9e329 to 97d84c8 Compare February 24, 2017 06:12

eddyb force-pushed the lazy-12 branch from 97d84c8 to 002a449 Compare February 25, 2017 09:43

This was referenced Feb 25, 2017

Fix type hint bug in eval_const_expr_partial() (issue #39548) #39812

Closed

Rollup of 29 pull requests #40089

Closed

eddyb mentioned this pull request Feb 25, 2017

Rollup of 28 pull requests #40091

Merged

eddyb added 7 commits February 25, 2017 17:07

rustc: store type parameter defaults outside of ty::Generics.

e8d01ea

rustc_typeck: simplify AstConv requests as implemented by collect.

86e4029

rustc: move the actual values of enum discriminants into a map.

e96a171

rustc: consolidate dep-tracked hashmaps in tcx.maps.

cc8a3a9

rustc: introduce a query system for type information in ty::maps.

b5c4244

rustc_mir: expose MIR building through ty::maps::Provider.

374ea14

rustc_typeck: lift CrateCtxt to TyCtxt.

4649f73

eddyb mentioned this pull request Feb 27, 2017

transition borrowck to visit all **bodies** and not item-likes #39927

Merged

rustc_save_analysis: don't pollute the codemap with fake files.

f702b20

bors merged commit f702b20 into rust-lang:master Feb 28, 2017

This was referenced Feb 28, 2017

Implementation of repr struct alignment RFC 1358. #39999

Merged

[MIR] Rvalue::ty infallible + remove TypedConstVal #40104

Merged

eddyb deleted the lazy-12 branch February 28, 2017 10:03

This was referenced Feb 28, 2017

[MIR] Implement Inlining #39648

Merged

[WIP] Simplify mismatched types by removing same subtypes #39906

Closed

Add catch {} to AST #39921

Merged

Simplify TokenTree and fix macro_rules! bugs #39419

Merged

oli-obk mentioned this pull request Mar 2, 2017

rustup to rustc 1.17.0-nightly (60a0edc6c 2017-02-26) rust-lang/miri#147

Merged

petrochenkov mentioned this pull request Mar 15, 2017

Add announcement post for 1.16 rust-lang/blog.rust-lang.org#153

Merged

eddyb mentioned this pull request Mar 27, 2017

Tracking issue for associated_consts feature #29646

Closed

6 tasks

bjorn3 mentioned this pull request Mar 29, 2021

Don't duplicate the extern providers once for each crate #83649

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[12/12] On-demand type-checking, const-evaluation, MIR building & const-qualification. #40008

[12/12] On-demand type-checking, const-evaluation, MIR building & const-qualification. #40008

eddyb commented Feb 21, 2017 •

edited

Loading

rust-highfive commented Feb 21, 2017

nikomatsakis left a comment

nikomatsakis Feb 22, 2017

nikomatsakis Feb 22, 2017

nikomatsakis Feb 22, 2017

nikomatsakis Feb 22, 2017

nikomatsakis Feb 22, 2017

nikomatsakis Feb 22, 2017

eddyb Feb 22, 2017

nikomatsakis Feb 23, 2017

nikomatsakis Feb 22, 2017

nikomatsakis Feb 22, 2017

eddyb Feb 22, 2017

nikomatsakis commented Feb 23, 2017

eddyb commented Feb 23, 2017

nikomatsakis commented Feb 23, 2017

eddyb commented Feb 24, 2017

bors commented Feb 24, 2017

eddyb commented Feb 25, 2017

bors commented Feb 25, 2017

bors commented Feb 25, 2017

eddyb commented Feb 25, 2017

frewsxcv commented Feb 25, 2017

bors commented Feb 26, 2017

eddyb commented Feb 26, 2017

eddyb commented Feb 26, 2017 •

edited

Loading

eddyb commented Feb 26, 2017

bors commented Feb 26, 2017

bors commented Feb 26, 2017

eddyb commented Feb 27, 2017 •

edited

Loading

eddyb commented Feb 28, 2017

bors commented Feb 28, 2017

bors commented Feb 28, 2017

bors commented Feb 28, 2017

[12/12] On-demand type-checking, const-evaluation, MIR building & const-qualification. #40008

[12/12] On-demand type-checking, const-evaluation, MIR building & const-qualification. #40008

Conversation

eddyb commented Feb 21, 2017 • edited Loading

User-facing changes

Compiler-internal changes

rust-highfive commented Feb 21, 2017

nikomatsakis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis commented Feb 23, 2017

eddyb commented Feb 23, 2017

nikomatsakis commented Feb 23, 2017

eddyb commented Feb 24, 2017

bors commented Feb 24, 2017

eddyb commented Feb 25, 2017

bors commented Feb 25, 2017

bors commented Feb 25, 2017

eddyb commented Feb 25, 2017

frewsxcv commented Feb 25, 2017

bors commented Feb 26, 2017

eddyb commented Feb 26, 2017

eddyb commented Feb 26, 2017 • edited Loading

eddyb commented Feb 26, 2017

bors commented Feb 26, 2017

bors commented Feb 26, 2017

eddyb commented Feb 27, 2017 • edited Loading

eddyb commented Feb 28, 2017

bors commented Feb 28, 2017

bors commented Feb 28, 2017

bors commented Feb 28, 2017

eddyb commented Feb 21, 2017 •

edited

Loading

eddyb commented Feb 26, 2017 •

edited

Loading

eddyb commented Feb 27, 2017 •

edited

Loading