-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Rolling up PRs in the queue #24674
Conversation
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.
This was moved to Stebalien/term#12
…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.
🔒 Merge conflict |
☔ The latest upstream changes (presumably #24162) made this pull request unmergeable. Please resolve the merge conflicts. |
💔 Test failed - auto-linux-64-opt |
@bors: retry force |
1 similar comment
@bors: retry force |
⚡ Previous build results for auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-64-nopt-t are reusable. Rebuilding only auto-linux-32-nopt-t, auto-linux-64-opt, auto-win-32-nopt-t, auto-win-32-opt, auto-win-64-opt... |
@bors: retry force clean |
No description provided.