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

ASCII methods on OsStr #69937

Merged
merged 5 commits into from
Mar 29, 2020
Merged

ASCII methods on OsStr #69937

merged 5 commits into from
Mar 29, 2020

Conversation

TyPR124
Copy link
Contributor

@TyPR124 TyPR124 commented Mar 11, 2020

Would close #69566

I don't know enough about encodings to know if this is a valid change, however the comment on the issue suggests it could be.

This does two things:

  1. Makes ASCII methods available on OsStr

  2. Makes it possible to obtain a &mut OsStr. This is necessary to actually use OsStr::make_ascii_*case methods since they modify the underlying value. As far as I can tell, the only way to modify a &mut OsStr is via the methods I just added.

My original hope was to have these methods on OsStrExt for Windows, since the standard library already assumes make_ascii_uppercase is valid in Windows (see the change I made to windows/process.rs). If it is found these are not valid changes on non-Windows platforms, I can move the methods to the ext trait instead.

@Dylan-DPC-zz
Copy link

r? @dtolnay

@Dylan-DPC-zz Dylan-DPC-zz added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 11, 2020
Copy link
Contributor

@mlodato517 mlodato517 left a comment

Choose a reason for hiding this comment

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

One small nitpick/question on where to place the doc links in the comments. Otherwise looks good to me but I'm too new to rust to approve or anything :-)

src/libstd/ffi/os_str.rs Outdated Show resolved Hide resolved
Copy link
Member

@dtolnay dtolnay left a comment

Choose a reason for hiding this comment

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

This looks great to me.

However, there is no such thing as an unstable impl of a stable trait for a stable type, so the new OsString trait impls will require consensus from the libs team to merge. Could you move just the IndexMut and DerefMut impls to a separate PR? We'll do an FCP to stabilize those, which should be uncontroversial, and then rebase and land the unstable ascii-related methods.

Thanks!

@Centril
Copy link
Contributor

Centril commented Mar 24, 2020

@TyPR124 👋 from triage, any progress?

@TyPR124
Copy link
Contributor Author

TyPR124 commented Mar 24, 2020

Still waiting on #70048 to be merged. Not sure how long that takes but it is in final comment period now.

@Dylan-DPC-zz Dylan-DPC-zz added S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 24, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Mar 27, 2020
Allow obtaining &mut OsStr

```rust
impl DerefMut for OsString {...}              // type Target = OsStr
impl IndexMut<RangeFull> for OsString {...}   // type Output = OsStr
```

---

This change is pulled out of rust-lang#69937 per @dtolnay

This implements `DerefMut for OsString` to allow obtaining a `&mut OsStr`. This also implements `IndexMut for OsString`, which is used by `DerefMut`. This pattern is the same as is used by `Deref`.

This is necessary to for methods like `make_ascii_lowercase` which need to mutate the underlying value.
@bors
Copy link
Contributor

bors commented Mar 27, 2020

☔ The latest upstream changes (presumably #70451) made this pull request unmergeable. Please resolve the merge conflicts.

@dtolnay dtolnay added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. labels Mar 28, 2020
@dtolnay
Copy link
Member

dtolnay commented Mar 28, 2020

Ready to rebase and then I can approve.

@TyPR124
Copy link
Contributor Author

TyPR124 commented Mar 28, 2020

I hope I did that right.

Do I need to open a tracking issue for this? Not totally sure how that works to be honest.

@dtolnay
Copy link
Member

dtolnay commented Mar 28, 2020

Thanks, this is just about ready. Yes, please follow the workflow in https://github.com/rust-lang/rust/issues/new/choose to open a tracking issue and then put the issue number in the attributes in the PR.

@dtolnay
Copy link
Member

dtolnay commented Mar 28, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Mar 28, 2020

📌 Commit 271d43b has been approved by dtolnay

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 28, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 29, 2020
Rollup of 5 pull requests

Successful merges:

 - rust-lang#69937 (ASCII methods on OsStr)
 - rust-lang#70235 (Validate git setup before accessing functionality)
 - rust-lang#70503 (rename Scalar::{ptr_null -> null_ptr} and add "machine_" prefix like elsewhere)
 - rust-lang#70508 (Miri: use more specialized Scalar::from_ constructors where appropriate)
 - rust-lang#70510 (fix TryEnterCriticalSection return type)

Failed merges:

r? @ghost
@bors
Copy link
Contributor

bors commented Mar 29, 2020

⌛ Testing commit 271d43b with merge 150322f...

@bors bors merged commit d584f5a into rust-lang:master Mar 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

make_ascii_lower/uppercase for Windows OsString?
6 participants