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

Improve docs in os::windows::ffi and os::windows::fs #41870

Merged
merged 8 commits into from
May 19, 2017
Merged

Improve docs in os::windows::ffi and os::windows::fs #41870

merged 8 commits into from
May 19, 2017

Conversation

randomPoison
Copy link
Contributor

Part of #29367

This PR makes changes to the documentation in os::windows::ffi and os::windows::fs with the goal of fleshing them out and bringing them in line with Rust's quality standards.

r? @steveklabnik

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @steveklabnik (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@TimNN TimNN added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 10, 2017
@TimNN
Copy link
Contributor

TimNN commented May 10, 2017

Hi @excaliburHisSheath and thanks for the PR! We'll periodically check in on it to make sure that @steveklabnik or someone else from the team reviews it soon.

@Mark-Simulacrum
Copy link
Member

@steveklabnik Just a reminder that this is still looking for a review from you.

cc @frewsxcv

@frewsxcv frewsxcv assigned frewsxcv and unassigned steveklabnik May 14, 2017
Copy link
Member

@frewsxcv frewsxcv left a comment

Choose a reason for hiding this comment

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

this is great, thanks so much! a couple small comments, and this is good to go

/// Re-encodes an `OsStr` as a wide character sequence, i.e. potentially
/// ill-formed UTF-16.
///
/// This is lossless: calling [`OsString::from_wide()`] and then
Copy link
Member

Choose a reason for hiding this comment

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

very minor, but can you remove all the () parens attached to method/function names in these docs? for the time being, the current policy is to remove them in documentation. see also #40456

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, I was under the impression that the () parens were the desired style, thanks for clarifying that this isn't the case (I can update documentation for my own crates as well).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For my own curiosity, is there some discussion around why the decision was made to remove the () parens when referencing function in documentation? Personally I liked that style, so I'm curious as to why the change was made.

Copy link
Member

Choose a reason for hiding this comment

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

It wasn't that a change was made; it was that while proposing https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md, we suggested that style, but it didn't make it through the process.

(I really like the ()s so I was just adding them in before we had an actual convention)

//! Provides access to platform-level information for Windows, and exposes
//! Windows-specific idioms that would otherwise be inappropriate as part
//! the core `std` library. These extensions allow developers to use
//! `std` types and idioms with Windows in a way that the noraml
Copy link
Member

Choose a reason for hiding this comment

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

typo: 'noraml'

///
/// # Examples
///
/// ```ignore
Copy link
Member

Choose a reason for hiding this comment

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

this example (and potentially other examples) could be no_run instead of ignore so they get compiled, but not run

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Cool, I wasn't aware of the distinction. Is there a general guideline to when examples should be no_run vs ignore vs tested normally?

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

the short answer is, if it doesn't compile, ignore, and if it compiles but you don't want it to run (say for example, a network test), then no_run.

Copy link
Member

@steveklabnik steveklabnik left a comment

Choose a reason for hiding this comment

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

This is great, thank you! Sorry for the delay here; I took two days at the end of last week off, so I'm a bit behind on reviews.

I agree with @frewsxcv 's comments, but have no other ones of my own. r=me after they're fixed 😄

@arielb1 arielb1 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 16, 2017
- Remove `()` parens when referencing functions in docs.
- Change some examples to be no_run instead of ignore.
- Normalize style in examples for `OpenOptionsExt`.
- Fix typo in windows mod docs.
@randomPoison
Copy link
Contributor Author

@frewsxcv I believe I've addressed your concerns. I've left a number of tests no_run since they'll create a file foo.txt and it seems like bad practice to have tests create random files on disk. If it's preferred that we run the tests anyway I can change them, I think the tests still pass when run.

I've also made some changes to make the code style for the various OpenOptionsExt examples more consistent.

@frewsxcv
Copy link
Member

Looks great, thanks!

@bors r+ rollup

@bors
Copy link
Contributor

bors commented May 19, 2017

📌 Commit 4cd838b has been approved by frewsxcv

@bors
Copy link
Contributor

bors commented May 19, 2017

⌛ Testing commit 4cd838b with merge 8d5a9ac...

@randomPoison
Copy link
Contributor Author

@frewsxcv Heads up, I pushed another commit after you approved because I noticed a doc test was failing. It doesn't look like the automated tests have caught the failure yet, though. I don't know if you need to do anything to make sure the new commit gets included in the merge.

@frewsxcv
Copy link
Member

@bors r+ rollup

@bors
Copy link
Contributor

bors commented May 19, 2017

📌 Commit a892925 has been approved by frewsxcv

Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request May 19, 2017
…-docs, r=frewsxcv

Improve docs in os::windows::ffi and os::windows::fs

Part of rust-lang#29367

This PR makes changes to the documentation in `os::windows::ffi` and `os::windows::fs` with the goal of fleshing them out and bringing them in line with Rust's quality standards.

r? @steveklabnik
bors added a commit that referenced this pull request May 19, 2017
@bors bors merged commit a892925 into rust-lang:master May 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants