Remove files with contributions from the people where no approval of the licensing terms was received

README.md

@@ -254,12 +254,12 @@ consensus and community norms, not impose more structure than necessary.
 ## License
 [License]: #license
 
-This repository is currently in the process of being licensed under either of
+Licensed under either of
 
 * Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)
 
-at your option. Some parts of the repository are already licensed according to those terms. For more see [RFC 2044](https://github.com/rust-lang/rfcs/pull/2044) and its [tracking issue](https://github.com/rust-lang/rust/issues/43461).
+at your option.
 
 ### Contributions
 

text/0066-better-temporary-lifetimes.md

@@ -1,62 +1 @@
-- Start Date: 2014-05-04
-- RFC PR: [rust-lang/rfcs#66](https://github.com/rust-lang/rfcs/pull/66)
-- Rust Issue: [rust-lang/rust#15023](https://github.com/rust-lang/rust/issues/15023)
-
-# Summary
-
-Temporaries live for the enclosing block when found in a let-binding. This only
-holds when the reference to the temporary is taken directly. This logic should
-be extended to extend the cleanup scope of any temporary whose lifetime ends up
-in the let-binding.
-
-For example, the following doesn't work now, but should:
-
-```rust
-use std::os;
-
-fn main() {
-	let x = os::args().slice_from(1);
-	println!("{}", x);
-}
-```
-
-# Motivation
-
-Temporary lifetimes are a bit confusing right now. Sometimes you can keep
-references to them, and sometimes you get the dreaded "borrowed value does not
-live long enough" error. Sometimes one operation works but an equivalent
-operation errors, e.g. autoref of `~[T]` to `&[T]` works but calling
-`.as_slice()` doesn't. In general it feels as though the compiler is simply
-being overly restrictive when it decides the temporary doesn't live long
-enough.
-
-# Drawbacks
-
-I can't think of any drawbacks.
-
-# Detailed design
-
-When a reference to a temporary is passed to a function (either as a regular
-argument or as the `self` argument of a method), and the function returns a
-value with the same lifetime as the temporary reference, the lifetime of the
-temporary should be extended the same way it would if the function was not
-invoked.
-
-For example, `~[T].as_slice()` takes `&'a self` and returns `&'a [T]`. Calling
-`as_slice()` on a temporary of type `~[T]` will implicitly take a reference
-`&'a ~[T]` and return a value `&'a [T]` This return value should be considered
-to extend the lifetime of the `~[T]` temporary just as taking an explicit
-reference (and skipping the method call) would.
-
-# Alternatives
-
-Don't do this. We live with the surprising borrowck errors and the ugly workarounds that look like
-
-```rust
-let x = os::args();
-let x = x.slice_from(1);
-```
-
-# Unresolved questions
-
-None that I know of.
+The file for this RFC has been removed, but the RFC is still in force and can be [read on GitHub](https://github.com/rust-lang/rfcs/blob/d046f391fa560839af3569be5b13b477a5aa29f9/text/0066-better-temporary-lifetimes.md).

text/0114-closures.md

@@ -80,7 +80,7 @@ invocation of one of the following traits:
     }
 
     trait FnOnce<A,R> {
-        fn call_once(self, args: A) -> R;
+        fn call_once(&self, args: A) -> R;
     }
 
 Essentially, `a(b, c, d)` becomes sugar for one of the following:
@@ -199,8 +199,8 @@ more programs successfully typecheck.
 ### By-reference closures
 
 A *by-reference* closure is a convenience form in which values used in
-the closure are converted into references before being captured. 
-By-reference closures are always rewritable into by-value closures if
+the closure are converted into references before being captured.  By
+reference closures are always rewritable into by value closures if
 desired, but the rewrite can often be cumbersome and annoying.
 
 Here is a (rather artificial) example of a by-reference closure in
@@ -368,7 +368,7 @@ TBD. pcwalton is working furiously as we speak.
 
 # Unresolved questions
 
-**What relationship should there be between the closure
+**What if any relationship should there be between the closure
 traits?** On the one hand, there is clearly a relationship between the
 traits.  For example, given a `FnShare`, one can easily implement
 `Fn`: