Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large reorgnization of rt::io::file #10086

Closed
wants to merge 3 commits into from

Conversation

alexcrichton
Copy link
Member

The goal of this reorganization is to finalize the interface into rt::io::file. The idea is to have this be the "pretty much final" interface, with room for only minor tweaks later on down the road.

More information can be found in the commits, but the major bonus of this pull is destroying all thread-blocking functions in std::os and moving a lot of code in preparation for making a native I/O factory (still to come later).

@alexcrichton
Copy link
Member Author

cc @olsonjeffery

///
/// # Failure
///
/// This funciton will raise on the `io_error` condition if an error
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spelling: funciton --> function :-)

@huonw
Copy link
Member

huonw commented Oct 26, 2013

I think it's a little peculiar that we're adding new APIs that repeat free-standing functions and methods, since we converted/are converting the other modules to use methods where possible.

@alexcrichton
Copy link
Member Author

That's actually a good point about freestanding functions vs methods. While I think that it's kinda convenient to be able to say path.open() it's not clear what exactly you're opening, so it's probably a good idea to put the file module in front of names.

On the other hand, it's pretty nice being able to say path.is_dir() and path.stat(). How about all read-only functions (querying about stat info basically) remain only as methods, except for file::stat being a function as well. Otherwise all actual modification functions become top-level functions. I believe that this means the list would be:

  • open
  • create
  • open_stream
  • rmdir
  • mkdir
  • rename
  • copy
  • unlink
  • remove_dir_recursive
  • make_dir_recursive
  • readdir

There's a few inconsistencies that I also see when looking over things:

  • There are a number of extra conditions raised in all the method versions of the top-level functions. I think that this is a case for merging them into one top-level function
  • It's odd to have rmdir, but remove_dir_recursive, these should have a unified name (same for mkdir)

@pcwalton
Copy link
Contributor

+1 on that.

@alexcrichton
Copy link
Member Author

Reorganized with top-level functions that are modifiers, and Path-functions that are queries (is_dir/is_file, etc). There is one duplicated function, and that is stat.

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.

The api of the io::file modules has also been reworked in this commit. The
open_reader and open_writer functions have had open and create counterparts
created, neither of which take any arguments (allowing for easy usage). The
top-level 'file::open' function was renamed to 'file::open_stream', and
top-level 'file::create' and 'file::open' functions were added (same as the
methods).

I also removed the traits that add functionality to the platform's Path
structure. It was unfortunate having to import all of these traits, and it was
unclear whether they would ever be implemented for anything other than Path. For
this reason, they're now just an extra impl block on Path itself.

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.

Closes rust-lang#10057
@alexcrichton
Copy link
Member Author

I'm just gonna do this all at once, don't want to leave things lingering.

flip1995 pushed a commit to flip1995/rust that referenced this pull request Dec 17, 2022
Fix new_return_no_self with recursive bounds

Fix rust-lang#10041

This uses a hash set, as described in rust-lang/rust-clippy#10068 (comment)

changelog: [`new_return_no_self`]: fix stack overflow when the return type is `impl Trait` and contains recursive bounds
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants