Begin finalizing the io::file module #10179
Conversation
|
Description updated. |
| use std::path::Path; | ||
| use std::rt::io; | ||
| use std::rt::io::file; | ||
| use std::rt::io::File; |
There was a problem hiding this comment.
yuck, capitalisation is the only distinction?
There was a problem hiding this comment.
The underlying distinction is that io::file is a module and io::File is a re-export of io::file::File for more ergonomic access.
I'm a little in favor of moving all of these functions to File instead of having some as top-level functions of io::file, but I was hesitant because they don't really have anything to do with files...
|
I think it's weird that the only reason one would import |
|
I'd be a little hesitant to crate a magical |
|
|
|
Hm, I actually quite like the name Additionally, I'm not sure that we need to keep the static methods any more. If we called the module |
|
New |
| /// | ||
| /// use std::rt::io::File; | ||
| /// | ||
| /// let contents = File::open("foo.txt").read_to_end(); |
There was a problem hiding this comment.
This should be using a Path, right?
These traits belong here, and were simply waiting for the std::io traits to get removed. It's time they take their rightful positions!
The invocation for making a directory should be able to specify a mode to make the directory with (instead of defaulting to one particular mode). Additionally, libuv and various OSes implement efficient versions of renaming files, so this operation is exposed as an IoFactory call.
This commit moves all thread-blocking I/O functions from the std::os module. Their replacements can be found in either std::rt::io::file or in a hidden "old_os" module inside of native::file. I didn't want to outright delete these functions because they have a lot of special casing learned over time for each OS/platform, and I imagine that these will someday get integrated into a blocking implementation of IoFactory. For now, they're moved to a private module to prevent bitrot and still have tests to ensure that they work. I've also expanded the extensions to a few more methods defined on Path, most of which were previously defined in std::os but now have non-thread-blocking implementations as part of using the current IoFactory. The api of io::file is in flux, but I plan on changing it in the next commit as well. Closes rust-lang#10057
This adds bindings to the remaining functions provided by libuv, all of which are useful operations on files which need to get exposed somehow. Some highlights: * Dropped `FileReader` and `FileWriter` and `FileStream` for one `File` type * Moved all file-related methods to be static methods under `File` * All directory related methods are still top-level functions * Created `io::FilePermission` types (backed by u32) that are what you'd expect * Created `io::FileType` and refactored `FileStat` to use FileType and FilePermission * Removed the expanding matrix of `FileMode` operations. The mode of reading a file will not have the O_CREAT flag, but a write mode will always have the O_CREAT flag. Closes rust-lang#10130 Closes rust-lang#10131 Closes rust-lang#10121
This renames the `file` module to `fs` because that more accurately describes its current purpose (manipulating the filesystem, not just files). Additionally, this adds an UnstableFileStat structure as a nested structure of FileStat to signify that the fields should not be depended on. The structure is currently flagged with #[unstable], but it's unlikely that it has much meaning. Closes rust-lang#10241
This fleshes out the io::file module a fair bit more, adding all of the functionality that I can think of that we would want. Some questions about the representation which I'm curious about: * I modified `FileStat` to be a little less platform-agnostic, but it's still fairly platform-specific. I don't want to hide information that we have, but I don't want to depend on this information being available. One possible route is to have an `extra` field which has all this os-dependent stuff which is clearly documented as it should be avoided. * Does it make sense for directory functions to be top-level functions instead of static methods? It seems silly to import `std::rt::io::file` and `std::rt::io::File` at the top of files that need to deal with directories and files.
…, r=xFrednet trim paths in `suspicious_to_owned` This continues my path trimming spree. I'm not going to add yet another changelog entry, we should have one "trim paths in some applicable lints" entry instead. --- changelog: none
This fleshes out the io::file module a fair bit more, adding all of the functionality that I can think of that we would want. Some questions about the representation which I'm curious about:
FileStatto be a little less platform-agnostic, but it's still fairly platform-specific. I don't want to hide information that we have, but I don't want to depend on this information being available. One possible route is to have anextrafield which has all this os-dependent stuff which is clearly documented as it should be avoided.std::rt::io::fileandstd::rt::io::Fileat the top of files that need to deal with directories and files.