| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r? @alexcrichton
|
|
Implement [RFC #1048][rfc].
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`.
[rfc]: https://github.com/rust-lang/rfcs/pull/1048
|
|
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`.
|
|
|
|
Looks like these were missed in bf4e77d.
|
|
Fixes #15679
Fixes #15878
Fixes #15882
Closes #15883
|
|
|
|
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
|
|
|
|
Fixes #21538.
|
|
|
|
Fixes #21538.
|
|
|
|
It's just as convenient, but it's much faster. Using write! requires an
extra call to fmt::write and a extra dynamically dispatched call to
Arguments' Display format function.
|
|
This patch
1. renames libunicode to librustc_unicode,
2. deprecates several pieces of libunicode (see below), and
3. removes references to deprecated functions from
librustc_driver and libsyntax. This may change pretty-printed
output from these modules in cases involving wide or combining
characters used in filenames, identifiers, etc.
The following functions are marked deprecated:
1. char.width() and str.width():
--> use unicode-width crate
2. str.graphemes() and str.grapheme_indices():
--> use unicode-segmentation crate
3. str.nfd_chars(), str.nfkd_chars(), str.nfc_chars(), str.nfkc_chars(),
char.compose(), char.decompose_canonical(), char.decompose_compatible(),
char.canonical_combining_class():
--> use unicode-normalization crate
|
|
This allows `io::Error` values to be stored in `Arc` properly.
Because this requires `Sync` of any value passed to `io::Error::new()`
and modifies the relevant `convert::From` impls, this is a
[breaking-change]
Fixes #24049.
|
|
Fixes #22190.
|
|
It's just as convenient, but it's much faster. Using write! requires an
extra call to fmt::write and a extra dynamically dispatched call to
Arguments' Display format function.
|
|
|
|
This patch
1. renames libunicode to librustc_unicode,
2. deprecates several pieces of libunicode (see below), and
3. removes references to deprecated functions from
librustc_driver and libsyntax. This may change pretty-printed
output from these modules in cases involving wide or combining
characters used in filenames, identifiers, etc.
The following functions are marked deprecated:
1. char.width() and str.width():
--> use unicode-width crate
2. str.graphemes() and str.grapheme_indices():
--> use unicode-segmentation crate
3. str.nfd_chars(), str.nfkd_chars(), str.nfc_chars(), str.nfkc_chars(),
char.compose(), char.decompose_canonical(), char.decompose_compatible(),
char.canonical_combining_class():
--> use unicode-normalization crate
|
|
One of the parameters to the magical "register a thread-local destructor"
function is called `__dso_handle` and largely just passed along (this seems to
be what other implementations do). Currently we pass the *value* of this symbol,
but apparently the correct piece of information to pass is the *address* of the
symbol.
In a PIE binary the symbol actually contains an address to itself which is why
we've gotten away with what we're doing as long as we have. In a non-PIE binary
the symbol contains the address `NULL`, causing a segfault in the runtime
library if it keeps going.
Closes #24445
|
|
r? @alexcrichton
|
|
- Also move common functions to test.rs
- Leaves out Socket address related tests in addr.rs
|
|
- Also move common functions to test.rs
- Leaves out Socket address related tests in addr.rs
|
|
One of the parameters to the magical "register a thread-local destructor"
function is called `__dso_handle` and largely just passed along (this seems to
be what other implementations do). Currently we pass the *value* of this symbol,
but apparently the correct piece of information to pass is the *address* of the
symbol.
In a PIE binary the symbol actually contains an address to itself which is why
we've gotten away with what we're doing as long as we have. In a non-PIE binary
the symbol contains the address `NULL`, causing a segfault in the runtime
library if it keeps going.
Closes #24445
|
|
|
|
This commit removes the last remnants of file descriptors from the Windows
implementation of `std::sys` by using `CreatePipe` to create anonymous pipes
instead of the `pipe` shim provided in msvcrt.
|
|
Fixes #22190.
|
|
This commit modifies the socket creation functions on windows to always specify
the `WSA_FLAG_OVERLAPPED` and `WSA_FLAG_NO_HANDLE_INHERIT` flags by default. The
overlapped flag enables IOCP APIs on Windows to be used with the socket at no
cost, enabling better interoperation with external libraries. The no handle
inherit flag mirrors the upcoming change to Unix to set CLOEXEC by default for
all handles.
Closes #24206
|
|
`s/([^\(\s]+\.)len\(\) [(?:!=)>] 0/!$1is_empty()/g`
|
|
`s/(?<!\{ self)(?<=\.)len\(\) == 0/is_empty()/g`
|
|
This commit removes the last remnants of file descriptors from the Windows
implementation of `std::sys` by using `CreatePipe` to create anonymous pipes
instead of the `pipe` shim provided in msvcrt.
|
|
|
|
This commit modifies the socket creation functions on windows to always specify
the `WSA_FLAG_OVERLAPPED` and `WSA_FLAG_NO_HANDLE_INHERIT` flags by default. The
overlapped flag enables IOCP APIs on Windows to be used with the socket at no
cost, enabling better interoperation with external libraries. The no handle
inherit flag mirrors the upcoming change to Unix to set CLOEXEC by default for
all handles.
Closes #24206
|
|
Conflicts:
src/libstd/thread/mod.rs
src/test/bench/shootout-mandelbrot.rs
src/test/bench/shootout-reverse-complement.rs
src/test/run-pass/capturing-logging.rs
src/test/run-pass/issue-9396.rs
src/test/run-pass/tcp-accept-stress.rs
src/test/run-pass/tcp-connect-timeouts.rs
src/test/run-pass/tempfile.rs
|
|
Conflicts:
src/libstd/net/ip.rs
src/libstd/sys/unix/fs.rs
src/libstd/sys/unix/mod.rs
src/libstd/sys/windows/mod.rs
|
|
r? @steveklabnik
|
|
It looks like `from_vec` was subsumed by new at some point,
but the documentation still refers to it as `from_vec`.
This updates the documentation for `from_vec_unchecked`
so that it properly says that it's the unchecked version of `new`.
Also, from_vec_unchecked requires a actual Vec<u8> while
new can take anything that is Into<Vec<u8>>, so I also
mention that in the documentation.
Since this is documentation:
r? @steveklabnik
|
|
- Adds two more functions for broadcast address and special
address classes reserved for documentation
- Modifies the globally routable IP check to include these
new functions
Fixes #24314
|
|
It was mistakenly calling `with_extension` with "foo.txt" instead of "txt".
I've also added an assert. This also calls more attention to the fact you get back a PathBuf, instead of a Path, which I feel is easy to miss when skimming.
|
|
The meaning of each variant of this enum was somewhat ambiguous and it's uncler
that we wouldn't even want to add more enumeration values in the future. As a
result this error has been altered to instead become an opaque structure.
Learning about the "first invalid byte index" is still an unstable feature, but
the type itself is now stable.
|
|
|
|
None of these actually compile any more!
|
|
|
|
Needed to get modules like rustc_back::tempdir compiling.
|
|
This commit entirely removes the old I/O, path, and rand modules. All
functionality has been deprecated and unstable for quite some time now!
|
|
|
|
As pointed out in [RFC issue 1043][rfc] it is quite useful to have the standard
I/O types to provide the contract that they are the sole owner of the underlying
object they represent. This guarantee enables writing safe interfaces like the
`MemoryMap` API sketched out in that issue.
[rfc]: https://github.com/rust-lang/rfcs/issues/1043
As constructing objects from these raw handles may end up violating these
ownership gurantees, the functions for construction are now marked unsafe.
[breaking-change]
Closes rust-lang/rfcs#1043
|
|
`thread::spawn` was previously restricted to closures that return `()`,
which limited the utility of joining on a spawned thread. However, there
is no reason for this restriction, and this commit allows arbitrary
return types.
Since it introduces a type parameter to `JoinHandle`, it's technically
a:
[breaking-change]
However, no code is actually expected to break.
|
|
|
