-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
ASCII methods on OsStr #69937
Conversation
r? @dtolnay |
There was a problem hiding this 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 :-)
There was a problem hiding this 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!
@TyPR124 👋 from triage, any progress? |
Still waiting on #70048 to be merged. Not sure how long that takes but it is in final comment period now. |
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.
☔ The latest upstream changes (presumably #70451) made this pull request unmergeable. Please resolve the merge conflicts. |
Ready to rebase and then I can approve. |
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. |
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. |
@bors r+ |
📌 Commit 271d43b has been approved by |
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
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:
Makes ASCII methods available on OsStr
Makes it possible to obtain a
&mut OsStr
. This is necessary to actually useOsStr::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 assumesmake_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.