summary refs log tree commit diff
path: root/src/test/incremental
AgeCommit message (Collapse)AuthorLines
2017-12-30Remove excessive trailing newlines.kennytm-5/+0
2017-12-18incr.comp.: Mark DepKind node as input.Michael Woerister-0/+24
2017-12-11move `resolve_lifetimes` into a proper queryNiko Matsakis-3/+12
Now that we made `resolve_lifetimes` into a query, elision errors no longer abort compilation, which affects some tests. Also, remove `dep_graph_crosscontaminate_tables` -- there is no a path in the dep-graph, though red-green handles it. The same scenario is (correctly) tested by issue-42602.rs in any case.
2017-12-08incr.comp.: Hash spans unconditionally for full accuracy.Michael Woerister-437/+130
2017-12-05Format function interface fingerprint hash testsJeff Crocker-56/+70
2017-12-05Update 'while loop' fingerprint hash testsJeff Crocker-54/+36
2017-12-05Update 'while let loop' fingerprint hash testsJeff Crocker-54/+36
2017-12-05Update loop expression fingerprint hash testsJeff Crocker-48/+32
2017-12-05Update inline asm fingerprint hash testsJeff Crocker-36/+24
2017-12-05Update function interface fingerprint hash testsJeff Crocker-108/+108
2017-12-05Update for loop fingerprint hash testsJeff Crocker-66/+44
2017-12-05Update closure expression fingerprint hash testsJeff Crocker-36/+24
2017-11-29incr.comp.: Update test cases after metadata hashing removal.Michael Woerister-1117/+5
2017-11-22modify inherent impls test to indicate `TypeckTables` do not changeNiko Matsakis-4/+40
I also added some comments explaining what is going on. In short, the changes in question do not, in fact, affect the`TypeckTables` in any semantic way. However, altering the order of lowering can cause it appear to affect the `TypeckTables`: if we lower generics before the body, then the `HirId` for things in the body will be affected. In this case, we are now lowering the generics etc *after* the body, so the hash no longer changes. This seems good.
2017-11-22Rollup merge of #45987 - gaurikholkar:let-expr, r=michaelwoeristerkennytm-210/+36
update let-expressions hash test to use `except` A part of #44924, this PR updated let-expressions test using `except`. cc @michaelwoerister r? @nikomatsakis
2017-11-16Rollup merge of #45951 - CrockAgile:master, r=michaelwoeristerGuillaume Gomez-145/+75
incr: Update hash tests to use `except`-style checking Part of #44924 r? @michaelwoerister
2017-11-14Remove checked arithmetic from if expression hash testsJeff Crocker-4/+4
2017-11-14Rollup merge of #45950 - ↵Guillaume Gomez-112/+56
fitzgen:update-unary-and-binary-exprs-test-to-use-incr-except, r=michaelwoerister incr: Make `unary_and_binary_exprs.rs` use `except`-style incremental checking Part of #44924 r? @michaelwoerister
2017-11-14Rollup merge of #45941 - gaurikholkar:master, r=nikomatsakisGuillaume Gomez-60/+47
update match-expressions.rs with DepNode labels As a part of #44924, I have updated the match-expressions.rs. The PR has tests verified for the following dependency nodes for let-expressions - MirValidated - MirOptimized - TypeCheckTables - TypeOfItem - GenericsOfItem - PredicatesOfItem - FnSignature cc @michaelwoerister r? @nikomatsakis
2017-11-14update let-expressions to use exceptgaurikholkar-210/+36
2017-11-13fixing indentationgaurikholkar-12/+12
2017-11-12Updated exported incremental compilation hash testsJeff Crocker-12/+6
2017-11-12Fix indexing expressions test copy/paste docsJeff Crocker-1/+1
2017-11-12Update if-expressions incremental hash testsJeff Crocker-32/+16
2017-11-12incr: Make `unary_and_binary_exprs.rs` use `except`-style incremental checkingNick Fitzgerald-112/+56
Part of #44924
2017-11-12Update panic expressions w/o overflow checks testsJeff Crocker-52/+26
2017-11-12Update panic expression incremental testsJeff Crocker-44/+22
2017-11-12tidy fixesgaurikholkar-1/+1
2017-11-12update match-expressions.rsgaurikholkar-60/+47
2017-11-10incr.comp.: Don't crash in DepGraph::try_mark_green() when encountering a ↵Michael Woerister-0/+47
removed input node.
2017-11-08Auto merge of #45867 - michaelwoerister:check-ich-stability, r=nikomatsakisbors-27/+64
incr.comp.: Verify stability of incr. comp. hashes and clean up various other things. The main contribution of this PR is that it adds the `-Z incremental-verify-ich` functionality. Normally, when the red-green tracking system determines that a certain query result has not changed, it does not re-compute the incr. comp. hash (ICH) for that query result because that hash is already known. `-Z incremental-verify-ich` tells the compiler to re-hash the query result and compare the new hash against the cached hash. This is a rather thorough way of - testing hashing implementation stability, - finding missing `[input]` annotations on `DepNodes`, and - finding missing read-edges, since both a missed read and a missing `[input]` annotation can lead to something being marked as green instead of red and thus will have a different hash than it should have. Case in point, implementing this verification logic and activating it for all `src/test/incremental` tests has revealed several such oversights, all of which are fixed in this PR. r? @nikomatsakis
2017-11-08incr.comp.: Adapt nested_items test to new HIR hashing rules.Michael Woerister-18/+18
2017-11-08incr.comp.: Make DefSpan an input dep-node so it is not affected by the ↵Michael Woerister-7/+9
existing Span/HIR hashing hack.
2017-11-07incr.comp.: Acknowledge the fact that shift operations can panic at runtime.Michael Woerister-2/+37
2017-11-07Fix incremental tests after change to instantiation strategy.Michael Woerister-275/+285
2017-11-03[Syntax Breaking] Rename DefaultImpl to AutoImplleonardo.yvens-2/+2
DefaultImpl is a highly confusing name for what we now call auto impls, as in `impl Send for ..`. The name auto impl is not formally decided but for sanity anything is better than `DefaultImpl` which refers neither to `default impl` nor to `impl Default`.
2017-11-01Auto merge of #45472 - michaelwoerister:incr-comp-caching-base, r=nikomatsakisbors-0/+19
incr.comp.: Implement compiler diagnostic persistence. This PR implements storing and loading diagnostics that the compiler generates and thus allows for emitting warnings during incremental compilation without actually re-evaluating the thing the warning originally came from. It also lays some groundwork for storing and loading type information and MIR in the incr. comp. cache. ~~It is still work in progress:~~ - ~~There's still some documentation to be added.~~ - ~~The way anonymous queries are handled might lead to duplicated emissions of warnings. Not sure if there is a better way or how frequent such duplication would be in practice.~~ Diagnostic message duplication is addressed separately in #45519. r? @nikomatsakis
2017-10-26incr.comp.: Update overflow-check logic in HIR hashing.Michael Woerister-40/+82
2017-10-25incr.comp.: Implement query diagnostic persistence.Michael Woerister-0/+19
2017-10-23update inherent_impls testsNiko Matsakis-6/+5
Now that we are visiting things in a different order during lowering, adding parameters winds up affecting the HirIds assigned to thinks in the method body, whereas it didn't before. We could fix this by reordering the order in which we visit `generics` during lowering, but this feels very fragile. Seems better to just let typeck tables be dirty here.
2017-10-14Auto merge of #45104 - vitiral:incr_auto_assert2, r=michaelwoeristerbors-446/+392
Incremental compilation auto assert (with except) cc @michaelwoerister bors merged part 1, so this is a WIP of part 2 of #45009 -- auto asserting DepNodes depending on the type of node rustc_clean/dirty is attached to Framework: - [x] finish auto-detection for specified DepNodes - [x] finish auto-detection for remaining DepNodes Test Refactors: - [x] consts.rs - [x] enum_constructors.rs - [x] extern_mods.rs - [x] inherent_impls.rs - [x] statics.rs - [x] struct_constructors.rs - ~~**BLOCKED** trait_defs.rs, see FIXME~~ - ~~**BLOCKED** trait_impls.rs~~ - [x] type_defs.rs - [x] enum_defs.rs
2017-10-13fix review commentsGarrett Berg-31/+34
2017-10-12incr comp: rustc_clean/dirty auto assertGarrett Berg-436/+379
This adds auto-assertion to `rustc_clean/dirty` and also implements more comprehensive testing for - src/test/incremental/hashes/enum_constructors.rs - src/test/incremental/hashes/enum_defs.rs - src/test/incremental/hashes/extern_mods.rs - src/test/incremental/hashes/inherent_impls.rs - src/test/incremental/hashes/statics.rs - src/test/incremental/hashes/struct_constructors.rs - src/test/incremental/hashes/type_defs.rs trait_defs.rs and trait_impl.rs are blocked on a hard to triage compiler ICE (at least hard for a newbie like me) having to do with some DepNodes not getting computed for traits. A FIXME has been added in the source to reflect this continued work.
2017-10-10Rollup merge of #45148 - gaurikholkar:master, r=nikomatsakisSteve Klabnik-0/+160
Update let-expressions.rs with DepNode labels As a part of #44924, the PR has tests verified for the following dependency nodes for **let-expressions** ``` - MirValidated - MirOptimized - TypeCheckTables - TypeOfItem - GenericsOfItem - PredicatesOfItem - FnSignature ``` As we are more concerned with the function body, the following fingerprints do not change over compilation sessions. ```- TypeOfItem - GenericsOfItem - PredicatesOfItem - FnSignature ``` r? @nikomatsakis cc @michaelwoerister P.S. Will add more tests as and when possible :)
2017-10-09Update let-expressions.rsgaurikholkar-0/+160
2017-10-09incr.comp.: Move macro-export test case to src/test/incremental.Michael Woerister-0/+22
2017-10-06Auto merge of #44951 - vitiral:incr_struct_defs, r=michaelwoeristerbors-4/+177
incr compilation struct_defs.rs I am prematurely openeing this as I need mentoring help from @michaelwoerister (also pinged @nikomatsakis) First, is this the right approach for these changes? Second, I'm a bit confused by the results so far. - Changing `TupleStructFieldType(i32)` -> `...(u32)` changes only Hir and HirBody, not TypeOfItem - Chaning `TupleStructAddField(i32)` -> `...(i32, u32)` *does* change TypeOfItem This seems wrong. I feel like it should change TypeOfItem in both cases. Is this a bug in incr compilation or is it expected?
2017-10-03related to #44924: update incr compilation for struct_defs.rsGarrett Berg-4/+177
2017-10-02incr.comp.: Use red/green tracking for CGU re-use.Michael Woerister-19/+14
2017-09-27Auto merge of #44709 - Badel2:inclusive-range-dotdoteq, r=petrochenkovbors-1/+1
Initial support for `..=` syntax #28237 This PR adds `..=` as a synonym for `...` in patterns and expressions. Since `...` in expressions was never stable, we now issue a warning. cc @durka r? @aturon