Skip to content

motor: Add new set_times stubs #147930

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Oct 21, 2025
Merged

motor: Add new set_times stubs #147930

merged 1 commit into from
Oct 21, 2025

Conversation

thaliaarchi
Copy link
Contributor

Motor OS std support (#147000) and set_times/set_times_nofollow (#147468) were merged around the same time, so Motor OS is missing this API and currently fails to build.

cc @lasiotus

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Oct 21, 2025
@rustbot
Copy link
Collaborator

rustbot commented Oct 21, 2025

r? @joboet

rustbot has assigned @joboet.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@thaliaarchi thaliaarchi mentioned this pull request Oct 21, 2025
Merged
@joboet
Copy link
Member

joboet commented Oct 21, 2025

@bors r+ rollup

@bors
Copy link
Collaborator

bors commented Oct 21, 2025

📌 Commit b39fb32 has been approved by joboet

It is now in the queue for this repository.

@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 Oct 21, 2025
@skorobogatydmitry skorobogatydmitry mentioned this pull request Oct 21, 2025
Closed
@matthiaskrgr matthiaskrgr mentioned this pull request Oct 21, 2025
Merged
@lasiotus
Copy link
Contributor

Motor OS std support (#147000) and set_times/set_times_nofollow (#147468) were merged around the same time, so Motor OS is missing this API and currently fails to build.

Thanks a lot for the fix!

bors added a commit that referenced this pull request Oct 21, 2025
@bors
Auto merge of #147943 - matthiaskrgr:rollup-rd0gb6y, r=matthiaskrgr
695857b 
Rollup of 3 pull requests

Successful merges:

 - #147929 (compiletest: Don't set `TARGET` for non run-make tests)
 - #147930 (motor: Add new `set_times` stubs)
 - #147934 (compiletest: More directive handling tweaks)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit e2110d8 into rust-lang:master Oct 21, 2025
11 checks passed
@rustbot rustbot added this to the 1.92.0 milestone Oct 21, 2025
rust-timer added a commit that referenced this pull request Oct 21, 2025
@rust-timer
Unrolled build for #147930
2cbd2e3 
Rollup merge of #147930 - thaliaarchi:motor-set-times, r=joboet

motor: Add new `set_times` stubs

Motor OS `std` support (#147000) and `set_times`/`set_times_nofollow` (#147468) were merged around the same time, so Motor OS is missing this API and currently fails to build.

cc `@lasiotus`
@thaliaarchi thaliaarchi deleted the motor-set-times branch October 21, 2025 22:02
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Oct 22, 2025
@matthiaskrgr
Rollup merge of rust-lang#147932 - thaliaarchi:utf8-osstring, r=tgross35
aa65c31 
Create UTF-8 version of `OsStr`/`OsString`

Implement a UTF-8 version of `OsStr`/`OsString`, in addition to the existing bytes and WTF-8 platform-dependent encodings.

This is applicable for several platforms, but I've currently only implemented it for Motor OS:

- WASI uses Unicode paths, but currently reexports the Unix bytes-assuming `OsStrExt`/`OsStringExt` traits.
  - [wasi:filesystem](https://wa.dev/wasi:filesystem) APIs:
    > Paths are passed as interface-type `strings`, meaning they must consist of a sequence of Unicode Scalar Values (USVs). Some filesystems may contain paths which are not accessible by this API.
  - In [wasi-filesystem#17](WebAssembly/wasi-filesystem#17 (comment)), it was decided that applications can use any Unicode transformation format, so we're free to use UTF-8 (and probably already do). This was chosen over specifically UTF-8 or an ad hoc encoding which preserves paths not representable in UTF-8.
      > The current API uses strings for filesystem paths, which contains sequences of Unicode scalar values (USVs), which applications can work with using strings encoded in UTF-8, UTF-16, or other Unicode encodings.
    >
    > This does mean that the API is unable to open files which do not have well-formed Unicode encodings, which may want separate APIs for handling such paths or may want something like the arf-strings proposal, but if we need that we should file a new issue for it.
- As of Redox OS [0.7.0](https://www.redox-os.org/news/release-0.7.0/), "All paths are now required to be UTF-8, and the kernel enforces this". This appears to have been implemented in commit [d331f72f](https://gitlab.redox-os.org/redox-os/kernel/-/commit/d331f72f2a51fa577072f24bc2587829fd87368b) (Use UTF-8 for all paths, 2021-02-14). Redox does not have `OsStrExt`/`OsStringExt`.
- Motor OS guarantees that its OS strings are UTF-8 in its [current `OsStrExt`/`OsStringExt` traits](https://github.com/moturus/rust/blob/a828ffcf5f04be5cdd91b5fad608102eabc17ec7/library/std/src/os/motor/ffi.rs), but they're still internally bytes like Unix.

This is an alternate approach to rust-lang#147797, which reuses the existing bytes `OsString` and relies on the safety properties of `from_encoded_bytes_unchecked`. Compared to that, this also gains efficiency from propagating the UTF-8 invariant to the whole type, as it never needs to test for UTF-8 validity.

Note that Motor OS currently does not build until rust-lang#147930 merges.

cc `@tgross35` (for earlier review)
cc `@alexcrichton,` `@rylev,` `@loganek` (for WASI)
cc `@lasiotus` (for Motor OS)
cc `@jackpot51` (for Redox OS)
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Oct 23, 2025
@matthiaskrgr
Rollup merge of #147932 - thaliaarchi:utf8-osstring, r=tgross35
8b5556a 
Create UTF-8 version of `OsStr`/`OsString`

Implement a UTF-8 version of `OsStr`/`OsString`, in addition to the existing bytes and WTF-8 platform-dependent encodings.

This is applicable for several platforms, but I've currently only implemented it for Motor OS:

- WASI uses Unicode paths, but currently reexports the Unix bytes-assuming `OsStrExt`/`OsStringExt` traits.
  - [wasi:filesystem](https://wa.dev/wasi:filesystem) APIs:
    > Paths are passed as interface-type `strings`, meaning they must consist of a sequence of Unicode Scalar Values (USVs). Some filesystems may contain paths which are not accessible by this API.
  - In [wasi-filesystem#17](WebAssembly/wasi-filesystem#17 (comment)), it was decided that applications can use any Unicode transformation format, so we're free to use UTF-8 (and probably already do). This was chosen over specifically UTF-8 or an ad hoc encoding which preserves paths not representable in UTF-8.
      > The current API uses strings for filesystem paths, which contains sequences of Unicode scalar values (USVs), which applications can work with using strings encoded in UTF-8, UTF-16, or other Unicode encodings.
    >
    > This does mean that the API is unable to open files which do not have well-formed Unicode encodings, which may want separate APIs for handling such paths or may want something like the arf-strings proposal, but if we need that we should file a new issue for it.
- As of Redox OS [0.7.0](https://www.redox-os.org/news/release-0.7.0/), "All paths are now required to be UTF-8, and the kernel enforces this". This appears to have been implemented in commit [d331f72f](https://gitlab.redox-os.org/redox-os/kernel/-/commit/d331f72f2a51fa577072f24bc2587829fd87368b) (Use UTF-8 for all paths, 2021-02-14). Redox does not have `OsStrExt`/`OsStringExt`.
- Motor OS guarantees that its OS strings are UTF-8 in its [current `OsStrExt`/`OsStringExt` traits](https://github.com/moturus/rust/blob/a828ffcf5f04be5cdd91b5fad608102eabc17ec7/library/std/src/os/motor/ffi.rs), but they're still internally bytes like Unix.

This is an alternate approach to rust-lang/rust#147797, which reuses the existing bytes `OsString` and relies on the safety properties of `from_encoded_bytes_unchecked`. Compared to that, this also gains efficiency from propagating the UTF-8 invariant to the whole type, as it never needs to test for UTF-8 validity.

Note that Motor OS currently does not build until rust-lang/rust#147930 merges.

cc `@tgross35` (for earlier review)
cc `@alexcrichton,` `@rylev,` `@loganek` (for WASI)
cc `@lasiotus` (for Motor OS)
cc `@jackpot51` (for Redox OS)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@joboet joboet

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Milestone

1.92.0

Development

Successfully merging this pull request may close these issues.

5 participants

@thaliaarchi @rustbot @joboet @bors @lasiotus