| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This commit stabilizes the `std::time` module and the `Duration` type.
`Duration::span` remains unstable, and the `Display` implementation for
`Duration` has been removed as it is still being reworked and all trait
implementations for stable types are de facto stable.
This is a [breaking-change] to those using `Duration`'s `Display`
implementation.
Conflicts:
src/librustc/lib.rs
src/libstd/time/duration.rs
|
|
The API we're calling requires us to pass an absolute point in time as an
argument (`pthread_cond_timedwait`) so we call `gettimeofday` ahead of time to
then add the specified duration to. Unfortuantely the current "add the duration"
logic forgot to take into account the current time's sub-second precision (e.g.
the `tv_usec` field was ignored), causing sub-second duration waits to return
spuriously.
|
|
This can fail on linux for various reasons, such as the /proc filesystem not
being mounted. There are already many cases where we can't set up stack guards,
so just don't worry about this case and communicate that no guard was enabled.
I've confirmed that this allows the compiler to run in a chroot without /proc
mounted.
Closes #22642
|
|
This can fail on linux for various reasons, such as the /proc filesystem not
being mounted. There are already many cases where we can't set up stack guards,
so just don't worry about this case and communicate that no guard was enabled.
I've confirmed that this allows the compiler to run in a chroot without /proc
mounted.
Closes #22642
|
|
This commit is an implementation of [RFC 1174][rfc] which adds three new traits
to the standard library:
* `IntoRawFd` - implemented on Unix for all I/O types (files, sockets, etc)
* `IntoRawHandle` - implemented on Windows for files, processes, etc
* `IntoRawSocket` - implemented on Windows for networking types
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1174-into-raw-fd-socket-handle-traits.md
Closes #27062
|
|
|
|
This makes `Debug` for `File` show the file path and access mode of the file on OS X, just like on Linux.
I'd be happy about any feedback how to make this code better. In particular, I'm not sure how to handle the buffer passed to `fnctl`. This way works, but it feels a bit cumbersome. `fcntl` unfortunately doesn't return the length of the path.
|
|
(On Windows, it works already.)
|
|
|
|
Using the OS mechanism for copying files allows the OS to optimize the transfer using stuff such as [Offloaded Data Transfers (ODX)](https://msdn.microsoft.com/en-us/library/windows/desktop/hh848056%28v=vs.85%29.aspx).
Also preserves a lot more information, including NTFS [File Streams](https://msdn.microsoft.com/en-us/library/windows/desktop/aa364404%28v=vs.85%29.aspx), which the manual implementation threw away.
In addition, it is an atomic operation, unlike the manual implementation which has extra calls for copying over permissions.
r? @alexcrichton
|
|
|
|
Adds a couple more tests for fs::copy
Signed-off-by: Peter Atashian <retep998@gmail.com>
|
|
|
|
|
|
non-Windows
|
|
|
|
signal(), sigemptyset(), and sigaddset() are only available as inline
functions until Android API 21. liblibc already handles signal()
appropriately, so drop it from c.rs; translate sigemptyset() and
sigaddset() (which is only used in a test) by hand from the C inlines.
We probably want to revert this commit when we bump Android API level.
|
|
Make sure that child processes don't get affected by libstd's desire to
ignore SIGPIPE, nor a third-party library's signal mask (which is needed
to use either a signal-handling thread correctly or to use signalfd /
kqueue correctly).
|
|
Both c.rs and stack_overflow.rs had bindings of libc's signal-handling
routines. It looks like the split dated from #16388, when (what is now)
c.rs was in libnative but not libgreen. Nobody is currently using the
c.rs bindings, but they're a bit more accurate in some places.
Move everything to c.rs (since I'll need signal handling in process.rs,
and we should avoid duplication), clean up the bindings, and manually
double-check everything against the relevant system headers (fixing a
few things in the process).
|
|
It looks like a lot of this dated to previous incarnations of the io
module, etc., and went unused in the reworking leading up to 1.0. Remove
everything we're not actively using (except for signal handling, which
will be reworked in the next commit).
|
|
The execv family of functions do not modify their arguments, so they do
not need mutable pointers. The C prototypes take a constant array of
mutable C-strings, but that's a legacy quirk from before C had const
(since C string literals have type `char *`). The Rust prototypes had
`*mut` in the wrong place, anyway: to match the C prototypes, it should
have been `*const *mut c_char`. But it is safe to pass constant strings
(like string literals) to these functions.
getopt is a special case, since GNU getopt modifies its arguments
despite the `const` claim in the prototype. It is apparently only
well-defined to call getopt on the actual argc and argv parameters
passed to main, anyway. Change it to take `*mut *mut c_char` for an
attempt at safety, but probably nobody should be using it from Rust,
since there's no great way to get at the parameters as passed to main.
Also fix the one caller of execvp in libstd, which now no longer needs
an unsafe cast.
Fixes #16290.
|
|
These were just left out by mistake!
|
|
Closes #25977
The various `stdfoo_raw` methods in std::io now return `io::Result`s,
since they may not exist on Windows. They will always return `Ok` on
Unix-like platforms.
[breaking-change]
|
|
Closes #25977
The various `stdfoo_raw` methods in std::io now return `io::Result`s,
since they may not exist on Windows. They will always return `Ok` on
Unix-like platforms.
[breaking-change]
|
|
This commit stabilizes the following APIs, slating them all to be cherry-picked
into the 1.1 release.
* fs::FileType (and transitively the derived trait implementations)
* fs::Metadata::file_type
* fs::FileType::is_dir
* fs::FileType::is_file
* fs::FileType::is_symlink
* fs::DirEntry::metadata
* fs::DirEntry::file_type
* fs::DirEntry::file_name
* fs::set_permissions
* fs::symlink_metadata
* os::raw::{self, *}
* os::{android, bitrig, linux, ...}::raw::{self, *}
* os::{android, bitrig, linux, ...}::fs::MetadataExt
* os::{android, bitrig, linux, ...}::fs::MetadataExt::as_raw_stat
* os::unix::fs::PermissionsExt
* os::unix::fs::PermissionsExt::mode
* os::unix::fs::PermissionsExt::set_mode
* os::unix::fs::PermissionsExt::from_mode
* os::unix::fs::OpenOptionsExt
* os::unix::fs::OpenOptionsExt::mode
* os::unix::fs::DirEntryExt
* os::unix::fs::DirEntryExt::ino
* os::windows::fs::MetadataExt
* os::windows::fs::MetadataExt::file_attributes
* os::windows::fs::MetadataExt::creation_time
* os::windows::fs::MetadataExt::last_access_time
* os::windows::fs::MetadataExt::last_write_time
* os::windows::fs::MetadataExt::file_size
The `os::unix::fs::Metadata` structure was also removed entirely, moving all of
its associated methods into the `os::unix::fs::MetadataExt` trait instead. The
methods are all marked as `#[stable]` still.
As some minor cleanup, some deprecated and unstable fs apis were also removed:
* File::path
* Metadata::accessed
* Metadata::modified
Features that were explicitly left unstable include:
* fs::WalkDir - the semantics of this were not considered in the recent fs
expansion RFC.
* fs::DirBuilder - it's still not 100% clear if the naming is right here and if
the set of functionality exposed is appropriate.
* fs::canonicalize - the implementation on Windows here is specifically in
question as it always returns a verbatim path. Additionally the Unix
implementation is susceptible to buffer overflows on long paths unfortunately.
* fs::PathExt - as this is just a convenience trait, it is not stabilized at
this time.
* fs::set_file_times - this funciton is still waiting on a time abstraction.
|
|
* Slate these features to be stable in 1.2 instead of 1.1 (not being backported)
* Have the `FromRawFd` implementations follow the contract of the `FromRawFd`
trait by taking ownership of the primitive specified.
* Refactor the implementations slightly to remove the `unreachable!` blocks as
well as separating the stdio representation of `std::process` from
`std::sys::process`.
|
|
This commit stabilizes the following APIs, slating them all to be cherry-picked
into the 1.1 release.
* fs::FileType (and transitively the derived trait implementations)
* fs::Metadata::file_type
* fs::FileType::is_dir
* fs::FileType::is_file
* fs::FileType::is_symlink
* fs::DirEntry::metadata
* fs::DirEntry::file_type
* fs::DirEntry::file_name
* fs::set_permissions
* fs::symlink_metadata
* os::raw::{self, *}
* os::{android, bitrig, linux, ...}::raw::{self, *}
* os::{android, bitrig, linux, ...}::fs::MetadataExt
* os::{android, bitrig, linux, ...}::fs::MetadataExt::as_raw_stat
* os::unix::fs::PermissionsExt
* os::unix::fs::PermissionsExt::mode
* os::unix::fs::PermissionsExt::set_mode
* os::unix::fs::PermissionsExt::from_mode
* os::unix::fs::OpenOptionsExt
* os::unix::fs::OpenOptionsExt::mode
* os::unix::fs::DirEntryExt
* os::unix::fs::DirEntryExt::ino
* os::windows::fs::MetadataExt
* os::windows::fs::MetadataExt::file_attributes
* os::windows::fs::MetadataExt::creation_time
* os::windows::fs::MetadataExt::last_access_time
* os::windows::fs::MetadataExt::last_write_time
* os::windows::fs::MetadataExt::file_size
The `os::unix::fs::Metadata` structure was also removed entirely, moving all of
its associated methods into the `os::unix::fs::MetadataExt` trait instead. The
methods are all marked as `#[stable]` still.
As some minor cleanup, some deprecated and unstable fs apis were also removed:
* File::path
* Metadata::accessed
* Metadata::modified
Features that were explicitly left unstable include:
* fs::WalkDir - the semantics of this were not considered in the recent fs
expansion RFC.
* fs::DirBuilder - it's still not 100% clear if the naming is right here and if
the set of functionality exposed is appropriate.
* fs::canonicalize - the implementation on Windows here is specifically in
question as it always returns a verbatim path. Additionally the Unix
implementation is susceptible to buffer overflows on long paths unfortunately.
* fs::PathExt - as this is just a convenience trait, it is not stabilized at
this time.
* fs::set_file_times - this funciton is still waiting on a time abstraction.
|
|
Closes #25619
r? @alexcrichton
|
|
This commit implements a number of standard traits for the standard library's
process I/O handles. The `FromRaw{Fd,Handle}` traits are now implemented for the
`Stdio` type and the `AsRaw{Fd,Handle}` traits are now implemented for the
`Child{Stdout,Stdin,Stderr}` types.
The stability markers for these implementations mention that they are stable for
1.1 as I will nominate this commit for cherry-picking to beta.
|
|
Closes #25619
|
|
|
|
The change to split up soft_link to OS-specific symlink, symlink_file,
and symlink_dir didn't actually land in 1.0.0. Update the stability and
deprecation attributes to correctly indicate that these changes happend
in 1.1.0.
|
|
This commits adds a method to the `std::process` module to get the process
identifier of the child as a `u32`. On Windows the underlying identifier is
already a `u32`, and on Unix the type is typically defined as `c_int` (`i32` for
almost all our supported platforms), but the actually pid is normally a small
positive number.
Eventually we may add functions to load information about a process based on its
identifier or the ability to terminate a process based on its identifier, but
for now this function should enable this sort of functionality to exist outside
the standard library.
|
|
[breaking-change]
|
|
This commit implements a number of standard traits for the standard library's
process I/O handles. The `FromRaw{Fd,Handle}` traits are now implemented for the
`Stdio` type and the `AsRaw{Fd,Handle}` traits are now implemented for the
`Child{Stdout,Stdin,Stderr}` types. Additionally this implements the
`AsRawHandle` trait for `Child` on Windows.
The stability markers for these implementations mention that they are stable for
1.1 as I will nominate this commit for cherry-picking to beta.
|
|
This commits adds a method to the `std::process` module to get the process
identifier of the child as a `u32`. On Windows the underlying identifier is
already a `u32`, and on Unix the type is typically defined as `c_int` (`i32` for
almost all our supported platforms), but the actually pid is normally a small
positive number.
Eventually we may add functions to load information about a process based on its
identifier or the ability to terminate a process based on its identifier, but
for now this function should enable this sort of functionality to exist outside
the standard library.
|
|
This commit is an implementation of [RFC 1040][rfc] which is a redesign of the
currently-unstable `Duration` type. The API of the type has been scaled back to
be more conservative and it also no longer supports negative durations.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1040-duration-reform.md
The inner `duration` module of the `time` module has now been hidden (as
`Duration` is reexported) and the feature name for this type has changed from
`std_misc` to `duration`. All APIs accepting durations have also been audited to
take a more flavorful feature name instead of `std_misc`.
Closes #24874
|
|
This commit is an implementation of [RFC 1040][rfc] which is a redesign of the
currently-unstable `Duration` type. The API of the type has been scaled back to
be more conservative and it also no longer supports negative durations.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1040-duration-reform.md
The inner `duration` module of the `time` module has now been hidden (as
`Duration` is reexported) and the feature name for this type has changed from
`std_misc` to `duration`. All APIs accepting durations have also been audited to
take a more flavorful feature name instead of `std_misc`.
Closes #24874
|
|
I've found that there are still huge amounts of occurrences of `task`s in the documentation. This PR tries to eliminate all of them in favor of `thread`.
|
|
This commit is an implementation of [RFC 1066][rfc] where the conclusion was
that leaking a value is a safe operation in Rust code, so updating the signature
of this function follows suit.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1066-safe-mem-forget.md
Closes #25186
|
|
An automated script was run against the `.rs` and `.md` files,
subsituting every occurrence of `task` with `thread`. In the `.rs`
files, only the texts in the comment blocks were affected.
|
|
This commit is an implementation of [RFC 1066][rfc] where the conclusion was
that leaking a value is a safe operation in Rust code, so updating the signature
of this function follows suit.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1066-safe-mem-forget.md
Closes #25186
|
|
Perform unsafe initialization up front and then only afterward the mutex is in
place do we initialize it.
|
|
Now that `std::old_io` has been removed for quite some time the naming real
estate here has opened up to allow these modules to move back to their proper
names.
|
|
|
|
|
|
|
|
These all had a typo where they were accessing the seconds field, not the
nanoseconds field.
|
|
These all had a typo where they were accessing the seconds field, not the
nanoseconds field.
|
|
Apparently implementations are allowed to return EDEADLK instead of blocking
forever, in which case this can lead to unsafety in the `RwLock` primitive
exposed by the standard library. A debug-build of the standard library would
have caught this error (due to the debug assert), but we don't ship debug
builds right now.
This commit adds explicit checks for the EDEADLK error code and triggers a panic
to ensure the call does not succeed.
Closes #25012
|
