https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=perf-tmp 2015-04-28T00:16:44+00:00 2015-04-28T00:16:44+00:00 Alex Crichton alex@alexcrichton.com 2015-04-16T06:21:13+00:00 urn:sha1:9348700007c6ac913df97c8e9e1ab7df6f91f130 This commit is an implementation of [RFC 1044][rfc] which adds additional surface area to the `std::fs` module. All new APIs are `#[unstable]` behind assorted feature names for each one. [rfc]: https://github.com/rust-lang/rfcs/pull/1044 The new APIs added are: * `fs::canonicalize` - bindings to `realpath` on unix and `GetFinalPathNameByHandle` on windows. * `fs::symlink_metadata` - similar to `lstat` on unix * `fs::FileType` and accessor methods as `is_{file,dir,symlink}` * `fs::Metadata::file_type` - accessor for the raw file type * `fs::DirEntry::metadata` - acquisition of metadata which is free on Windows but requires a syscall on unix. * `fs::DirEntry::file_type` - access the file type which may not require a syscall on most platforms. * `fs::DirEntry::file_name` - access just the file name without leading components. * `fs::PathExt::symlink_metadata` - convenience method for the top-level function. * `fs::PathExt::canonicalize` - convenience method for the top-level function. * `fs::PathExt::read_link` - convenience method for the top-level function. * `fs::PathExt::read_dir` - convenience method for the top-level function. * `std::os::raw` - type definitions for raw OS/C types available on all platforms. * `std::os::$platform` - new modules have been added for all currently supported platforms (e.g. those more specific than just `unix`). * `std::os::$platform::raw` - platform-specific type definitions. These modules are populated with the bare essentials necessary for lowing I/O types into their raw representations, and currently largely consist of the `stat` definition for unix platforms. This commit also deprecates `Metadata::{modified, accessed}` in favor of inspecting the raw representations via the lowering methods of `Metadata`. 2015-04-23T15:58:47+00:00 Alex Crichton alex@alexcrichton.com 2015-04-23T15:58:47+00:00 urn:sha1:a318b5134667f30395fb0036ea3dd987bf8e1766 These functions were intended to be introduced as `#[stable]` as a stable API was deprecated in favor of them, but they just erroneously forgot the stability attributes. 2015-04-21T16:14:22+00:00 Brian Campbell lambda@continuation.org 2015-04-09T07:22:44+00:00 urn:sha1:3cc84efcdd5727c0749d766d8abd79d8077f9cec 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`. 2015-04-14T17:56:57+00:00 Alex Crichton alex@alexcrichton.com 2015-04-14T17:56:57+00:00 urn:sha1:ae7959d298c95d5ffdeae8e7c3f3659d7fc28cdb Conflicts: src/libstd/net/ip.rs src/libstd/sys/unix/fs.rs src/libstd/sys/unix/mod.rs src/libstd/sys/windows/mod.rs 2015-04-14T17:14:11+00:00 Alex Crichton alex@alexcrichton.com 2015-04-10T00:42:22+00:00 urn:sha1:bf4e77d4b543632ca4df8fdd7092850dffc3954b This commit entirely removes the old I/O, path, and rand modules. All functionality has been deprecated and unstable for quite some time now! 2015-04-13T17:57:51+00:00 Andrew Paseltiner apaseltiner@gmail.com 2015-04-13T14:21:32+00:00 urn:sha1:6fa16d6a473415415cb87a1fe6754aace32cbb1c 2015-04-09T23:12:33+00:00 Alex Crichton alex@alexcrichton.com 2015-04-09T22:43:27+00:00 urn:sha1:2705051e2067e8f467b4cb9bc75e801a5cd4f0e7 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 2015-03-26T23:40:36+00:00 Alex Crichton alex@alexcrichton.com 2015-03-26T23:18:29+00:00 urn:sha1:6370f2978e485fd46bcb64f51a1c003395acfedc This commit stabilizes the platform-specific `io` modules, specifically around the traits having to do with the raw representation of each object on each platform. Specifically, the following material was stabilized: * `AsRaw{Fd,Socket,Handle}` * `RawFd` (renamed from `Fd`) * `RawHandle` (renamed from `Handle`) * `RawSocket` (renamed from `Socket`) * `AsRaw{Fd,Socket,Handle}` implementations * `std::os::{unix, windows}::io` The following material was added as `#[unstable]`: * `FromRaw{Fd,Socket,Handle}` * Implementations for various primitives There are a number of future improvements that are possible to make to this module, but this should cover a good bit of functionality desired from these modules for now. Some specific future additions may include: * `IntoRawXXX` traits to consume the raw representation and cancel the auto-destructor. * `Fd`, `Socket`, and `Handle` abstractions that behave like Rust objects and have nice methods for various syscalls. At this time though, these are considered backwards-compatible extensions and will not be stabilized at this time. This commit is a breaking change due to the addition of `Raw` in from of the type aliases in each of the platform-specific modules. [breaking-change] 2015-03-15T17:28:34+00:00 Alex Crichton alex@alexcrichton.com 2015-03-14T00:12:38+00:00 urn:sha1:1f5f76adc36082ec514a6cfa4ad2d7e6655a5253 This commit starts to organize the `std::os::$platform` modules and in the process stabilizes some of the functionality contained within. The organization of these modules will reflect the organization of the standard library itself with extension traits for primitives in the same corresponding module. The OS-specific modules will grow more functionality over time including concrete types that are not extending functionality of other structures, and these will either go into the closest module in `std::os::$platform` or they will grow a new module in the hierarchy. The following items are now stable: * `os::{unix, windows}` * `unix::ffi` * `unix::ffi::OsStrExt` * `unix::ffi::OsStrExt::{from_bytes, as_bytes, to_cstring}` * `unix::ffi::OsString` * `unix::ffi::OsStringExt::{from_vec, into_vec}` * `unix::process` * `unix::process::CommandExt` * `unix::process::CommandExt::{uid, gid}` * `unix::process::ExitStatusExt` * `unix::process::ExitStatusExt::signal` * `unix::prelude` * `windows::ffi` * `windows::ffi::OsStringExt` * `windows::ffi::OsStringExt::from_wide` * `windows::ffi::OsStrExt` * `windows::ffi::OsStrExt::encode_wide` * `windows::prelude` The following items remain unstable: * `unix::io` * `unix::io::{Fd, AsRawFd}` * `unix::fs::{PermissionsExt, OpenOptionsExt}` * `windows::io` * `windows::io::{Handle, AsRawHandle}` * `windows::io::{Socket, AsRawSocket}` * `windows::fs` * `windows::fs::OpenOptionsExt` Due to the reorgnization of the platform extension modules, this commit is a breaking change. Most imports can be fixed by adding the relevant libstd module in the `use` path (such as `ffi` or `fs`). [breaking-change] 2015-03-13T17:00:28+00:00 Alex Crichton alex@alexcrichton.com 2015-03-11T22:24:14+00:00 urn:sha1:981bf5f690d1d7c5cf3e1419ac7a7c86dbc7a4d5