Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rolling up PRs in the queue #24674

Merged
merged 59 commits into from
Apr 22, 2015
Merged

Rolling up PRs in the queue #24674

merged 59 commits into from
Apr 22, 2015

Conversation

alexcrichton
Copy link
Member

No description provided.

alexcrichton and others added 30 commits April 17, 2015 16:37
This is an implementation of [RFC 1030][rfc] which adds these traits to the
prelude and additionally removes all inherent `into_iter` methods on collections
in favor of the trait implementation (which is now accessible by default).

[rfc]: rust-lang/rfcs#1030

This is technically a breaking change due to the prelude additions and removal
of inherent methods, but it is expected that essentially no code breaks in
practice.

[breaking-change]
Closes rust-lang#24538
Looks like these were missed in bf4e77d.
…ies.

Note: this Warns rather than error on shadowing problems involving labels.
We took this more conservative option mostly due to issues with
hygiene being broken for labels and/or lifetimes.

Add FIXME regarding non-hygienic comparison.
On Windows, when you create a symbolic link you must specify whether it
points to a directory or a file, even if it is created dangling, while
on Unix, the same symbolic link could point to a directory, a file, or
nothing at all.  Furthermore, on Windows special privilege is necessary
to use a symbolic link, while on Unix, you can generally create a
symbolic link in any directory you have write privileges to.

This means that it is unlikely to be able to use symbolic links purely
portably; anyone who uses them will need to think about the cross
platform implications.  This means that using platform-specific APIs
will make it easier to see where code will need to differ between the
platforms, rather than trying to provide some kind of compatibility
wrapper.

Furthermore, `soft_link` has no precedence in any other API, so to avoid
confusion, move back to the more standard `symlink` terminology.

Create a `std::os::unix::symlink` for the Unix version that is
destination type agnostic, as well as `std::os::windows::{symlink_file,
symlink_dir}` for Windows.

Because this is a stable API, leave a compatibility wrapper in
`std::fs::soft_link`, which calls `symlink` on Unix and `symlink_file`
on Windows, preserving the existing behavior of `soft_link`.
Replace Path::exists with stable metadata call.
@alexcrichton
Copy link
Member Author

@bors: r+ d56a726

@alexcrichton
Copy link
Member Author

@bors: r+ c71bfb0

@alexcrichton
Copy link
Member Author

@bors: r+ 224fc10

@bors
Copy link
Contributor

bors commented Apr 21, 2015

🔒 Merge conflict

@bors
Copy link
Contributor

bors commented Apr 21, 2015

☔ The latest upstream changes (presumably #24162) made this pull request unmergeable. Please resolve the merge conflicts.

@alexcrichton
Copy link
Member Author

@bors: r+ 5815064 force

@bors
Copy link
Contributor

bors commented Apr 21, 2015

⌛ Testing commit 5815064 with merge 8c6cad0...

@bors
Copy link
Contributor

bors commented Apr 22, 2015

💔 Test failed - auto-linux-64-opt

@alexcrichton
Copy link
Member Author

@bors: retry force

1 similar comment
@alexcrichton
Copy link
Member Author

@bors: retry force

@bors
Copy link
Contributor

bors commented Apr 22, 2015

@alexcrichton
Copy link
Member Author

@bors: retry force clean

@bors
Copy link
Contributor

bors commented Apr 22, 2015

⌛ Testing commit 5815064 with merge c0eb938...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.