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

Emphasise that an OsStr[ing] is not necessarily a platform string #91467

Merged
merged 1 commit into from
Dec 8, 2021

Conversation

ChrisDenton
Copy link
Member

Fixes #53261

Since that issue was filed, #56141 added a further clarification to the OsString docs. However the ffi docs may still leave the impression that an OsStr is in the platform native form. This PR aims to further emphasise that an OsStr is not necessarily a platform string.

@rust-highfive
Copy link
Collaborator

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 2, 2021
@Mark-Simulacrum
Copy link
Member

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Dec 7, 2021

📌 Commit 49aa5ba has been approved by Mark-Simulacrum

@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-review Status: Awaiting review from the assignee but also interested parties. labels Dec 7, 2021
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 7, 2021
…Mark-Simulacrum

Emphasise that an OsStr[ing] is not necessarily a platform string

Fixes rust-lang#53261

Since that issue was filed, rust-lang#56141 added a further clarification to the `OsString` docs. However the ffi docs may still leave the impression that an `OsStr` is in the platform native form. This PR aims to further emphasise that an `OsStr` is not necessarily a platform string.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 8, 2021
…Mark-Simulacrum

Emphasise that an OsStr[ing] is not necessarily a platform string

Fixes rust-lang#53261

Since that issue was filed, rust-lang#56141 added a further clarification to the `OsString` docs. However the ffi docs may still leave the impression that an `OsStr` is in the platform native form. This PR aims to further emphasise that an `OsStr` is not necessarily a platform string.
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 8, 2021
…askrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#83744 (Deprecate crate_type and crate_name nested inside #![cfg_attr])
 - rust-lang#90550 (Update certificates in some Ubuntu 16 images.)
 - rust-lang#91272 (Print a suggestion when comparing references to primitive types in `const fn`)
 - rust-lang#91467 (Emphasise that an OsStr[ing] is not necessarily a platform string)
 - rust-lang#91531 (Do not add `;` to expected tokens list when it's wrong)
 - rust-lang#91577 (Address some FIXMEs left over from rust-lang#91475)
 - rust-lang#91638 (Remove `in_band_lifetimes` from `rustc_mir_transform`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit bb8a4ab into rust-lang:master Dec 8, 2021
@rustbot rustbot added this to the 1.59.0 milestone Dec 8, 2021
@ChrisDenton ChrisDenton deleted the confusing-os-string branch December 8, 2021 14:29
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.

I found the OsStr(ing) documentation misleading w.r.t. Windows
5 participants