about summary refs log tree commit diff
path: root/src/test/incremental/change_private_impl_method_cc
AgeCommit message (Collapse)AuthorLines
2023-01-11Move /src/test to /testsAlbert Larsan-98/+0
2021-05-15Remove `label` in dirty/clean annotations.Camille GILLOT-5/+5
2020-07-17Rename TypeckTables to TypeckResults.Valentin Lazureanu-5/+5
2019-07-03Migrate compile-pass annotations to build-passYuki Okushi-1/+1
2019-03-30Update testsJohn Kåre Alsaker-5/+5
2018-12-25Remove licensesMark Rousskov-20/+0
2018-04-13Rename must-compile-successfully into compile-passGuillaume Gomez-1/+1
2017-11-07Fix incremental tests after change to instantiation strategy.Michael Woerister-21/+20
2017-10-02incr.comp.: Use red/green tracking for CGU re-use.Michael Woerister-2/+0
2017-09-23incr.comp.: Remove support for loading metadata fingerprints.Michael Woerister-0/+2
2017-05-18Enable cross-crate incremental compilation by default.Michael Woerister-2/+0
2017-01-27Auto merge of #39281 - michaelwoerister:make-cc-incr-comp-opt-in, r=nikomatsakisbors-0/+2
incr.comp.: Make cross-crate tracking for incr. comp. opt-in. The current implementation of cross-crate dependency tracking can cause quite long compile times and high memory usage for some crates (see #39208 for example). This PR therefore makes that part of dependency tracking optional. Incremental compilation still works, it will only have very coarse dep-tracking for upstream crates. r? @nikomatsakis
2017-01-25rename `Tables` to `TypeckTables`Niko Matsakis-5/+5
2017-01-25merge TypeckItemBody and Tables depnodesNiko Matsakis-5/+5
2017-01-24incr.comp.: Make cross-crate tracking for incr. comp. opt-in.Michael Woerister-0/+2
2016-11-29restructure `CollectItem` dep-node to separate fn sigs from bodiesNiko Matsakis-7/+4
Setup two tasks, one of which only processes the signatures, in order to isolate the typeck entries for signatures from those for bodies. Fixes #36078 Fixes #37720
2016-11-17fix change_private_impl_method_cc testNiko Matsakis-3/+1
2016-11-17when creating an AssociatedItem, read data from impl, not impl itemNiko Matsakis-13/+13
Before, when we created an AssociatedItem for impl item X, we would read the impl item itself. Now we instead load up the impl I that contains X and read the data from the `ImplItemRef` for X; actually, we do it for all impl items in I pre-emptively. This kills the last source of edges between a method X and a call to a method Y defined in the same impl. Fixes #37121
2016-10-21add a test case for changing a private impl method across cratesNiko Matsakis-0/+124
Currently doesn't work that well at all in terms of getting reuse afterwards, see #37333. =)