Make `fold` standalone.

`fold` is currently implemented via `try_fold`, but implementing it
directly results in slightly less LLVM IR being generated, speeding up
compilation of some benchmarks.

(And likewise for `rfold`.)

The commit adds `fold` implementations to all the iterators that lack
one but do have a `try_fold` implementation. Most of these just call the
`try_fold` implementation directly.

2 files changed, 0 insertions, 24 deletions

diff --git a/src/test/codegen/iter-fold-closure-no-dupes.rs b/src/test/codegen/iter-fold-closure-no-dupes.rs
deleted file mode 100644
index ec58f7068ab..00000000000
--- a/src/test/codegen/iter-fold-closure-no-dupes.rs
+++ /dev/null
@@ -1,14 +0,0 @@
-//! Check that fold closures aren't duplicated for each iterator type.
-// compile-flags: -C opt-level=0
-
-fn main() {
-    (0i32..10).by_ref().count();
-    (0i32..=10).by_ref().count();
-}
-
-// `count` calls `fold`, which calls `try_fold` -- find the `fold` closure:
-// CHECK: {{^define.*Iterator::fold::.*closure}}
-//
-// Only one closure is needed for both `count` calls, even from different
-// monomorphized iterator types, as it's only generic over the item type.
-// CHECK-NOT: {{^define.*Iterator::fold::.*closure}}
diff --git a/src/test/codegen/iter-fold-closure-no-iterator.rs b/src/test/codegen/iter-fold-closure-no-iterator.rs
deleted file mode 100644
index fbeafd5f395..00000000000
--- a/src/test/codegen/iter-fold-closure-no-iterator.rs
+++ /dev/null
@@ -1,10 +0,0 @@
-//! Check that fold closures aren't generic in the iterator type.
-// compile-flags: -C opt-level=0
-
-fn main() {
-    (0i32..10).by_ref().count();
-}
-
-// `count` calls `fold`, which calls `try_fold` -- that `fold` closure should
-// not be generic in the iterator type, only in the item type.
-// CHECK-NOT: {{^define.*Iterator::fold::.*closure.*Range}}