Derive Copy for std::ops::Range and RangeFrom

[SimonSapin]

RangeTo and RangeFull already have it.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @pcwalton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[eddyb]

These don't have it because they're iterators.
The choice of removing Copy impls instead of adjusted for loop desugaring or linting was made to prevent this problematic case:

let mut iter = 0..n;
for i in iter { if i > 2 { break; } }
iter.collect()

Here iter is actually not mutated, but copied. for i in &mut iter is required to mutate the iterator.
We could switch to linting against using an iterator variable after it was copied by a for loop, but there was no decision towards that.

[SimonSapin]

Ok, so there was a reason.

“The choice […] was made” seems to contradict “no decision has been made yet.” If the decision against implementing Copy is made/confirmed, feel free to close this.

[alexcrichton]

Yeah we've decided in the past to not take this, so I'm going to close this for now.

[eddyb]

@SimonSapin original phrasing was a bit off. What I meant to say was that no decision has been made for switching to linting (which my personal preference).

[sanmai-NL]

I favor a lint, since this code pattern is now not possible:

let three_times = 0_u32..3_u32;
for _ in three_times {
    ...
}
for _ in three_times {
    ...
}