Skip to content

clarify docs for std:io::fs::Path::{is_dir,is_file,exists}; add lstat #13750

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

Closed
wants to merge 1 commit into from

Conversation

aturon
Copy link
Member

@aturon aturon commented Apr 25, 2014

Clarifies the interaction of is_dir, is_file and exists with
symbolic links. Adds a convenience lstat function alongside of
stat. Removes references to conditions.

Closes issue #12583.

///
/// Will not raise a condition
/// This call preserves identical runtime/error semantics with `file::lstat`.
pub fn lstat(&self) -> IoResult<FileStat> { stat(self) }
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm pretty sure you meant to call lstat(self) here.

@lilyball
Copy link
Contributor

Are there any tests for std::io::fs::stat() and lstat()? If so, could we get some basic coverage for Path::stat() and Path::lstat() as well? The bug I pointed out here (where you called stat() in the implementation of Path::lstat()) is something that I'd rather see caught by tests.

@lilyball
Copy link
Contributor

r=me with my comments addressed and some minimal tests added.

@aturon
Copy link
Member Author

aturon commented Apr 25, 2014

@kballard I've now expanded existing unit tests for stat and lstat to also check the convenience methods.

As a sidenote, the rationale for when functionality should be exposed as a function versus a method (or both) wasn't entirely clear to me. I brought it up on IRC, but discussion was inconclusive -- the main benefit of methods seem to be that you don't need imports to get access to them. In any case, it seems a shame to have (notably, error-prone) boilerplate like these wrapper methods, which then requires redundant testing. But for this patch, I'm sticking with the existing pattern.

///
/// # Error
/// Consult the `file::lstat` documentation for more info.
Copy link
Member

Choose a reason for hiding this comment

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

fs::lstat

Copy link
Member

Choose a reason for hiding this comment

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

(and below)

Clarifies the interaction of `is_dir`, `is_file` and `exists` with
symbolic links.  Adds a convenience `lstat` function alongside of
`stat`.  Removes references to conditions.

Closes issue rust-lang#12583.
@aturon
Copy link
Member Author

aturon commented Apr 25, 2014

@alexcrichton fixed, thanks.

@alexcrichton
Copy link
Member

lstat is currently unimplemented on windows, so the tests which are exercising lstat may need some calls to if !cfg!(windows) { ... }

@aturon
Copy link
Member Author

aturon commented Apr 25, 2014

@alexcrichton yep -- I only added method-based lstat tests where there were existing function-based lstat tests, which are all already checking against cfg!(windows).

bors added a commit that referenced this pull request Apr 26, 2014
Clarifies the interaction of `is_dir`, `is_file` and `exists` with
symbolic links.  Adds a convenience `lstat` function alongside of
`stat`.  Removes references to conditions.

Closes issue #12583.
@bors bors closed this Apr 26, 2014
arcnmx pushed a commit to arcnmx/rust that referenced this pull request Dec 17, 2022
…bold

fix: normalize projection after discarding free `BoundVar`s in RPIT

Fixes rust-lang#13307

When we lower the return type of a function, it may contain free `BoundVar`s in `OpaqueType`'s substitution, which would cause panic during canonicalization as part of projection normalization. Those `BoundVar`s are irrelevant in this context and will be discarded, and we should defer projection normalization until then.
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