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`.
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.
This patch adds a `Debug` impl for `std::fs::File`.
On all platforms (Unix and Windows) it shows the file descriptor.
On Linux, it displays the path and access mode as well.
Ideally we should show the path/mode for all platforms, not just Linux,
but this will do for now.
cc #24570
This patch adds a `Debug` impl for `std::fs::File`.
On all platforms (Unix and Windows) it shows the file descriptor.
On Linux, it displays the path and access mode as well.
Ideally we should show the path/mode for all platforms, not just Linux,
but this will do for now.
cc #24570
Many unsafe features are now in the unstable section, so this section is
really just about raw pointers now. That also makes sense for its place
in the TOC.
This addresses part of #12905.
Without the `box` keyword, one of these two reasons is not correct, so
let's just eliminate this section and elaborate on the reason for the
legit use case inline.
Fixes#24511
Fixes#24173
These docs could all use examples, so for now, let's just remove the bad one, and when I go over this whole module I'll put in better ones.
When `liballoc` is compiled with `--cfg feature=\"external_features\"`, several `improper_ctypes` warnings are generated. Since these warnings are harmless, I have added a directive to suppress them.
Many unsafe features are now in the unstable section, so this section is
really just about raw pointers now. That also makes sense for its place
in the TOC.
This addresses part of #12905.
Erick Tryzelaar
John Van Enk
Simon Sapin
Brian Campbell
Felix S. Klock II
Tamir Duberstein
Young Wu
bors
Steve Klabnik
Piotr Czarnecki
Chris Wong
mdinger
Matt Brubeck
Brian Anderson
Tshepang Lekhonkhobe