Skip to content

std::fs: get_mode implementation for all unix #128962

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

Merged
merged 2 commits into from
Aug 13, 2024

Conversation

devnexen
Copy link
Contributor

No description provided.

@rustbot
Copy link
Collaborator

rustbot commented Aug 11, 2024

r? @workingjubilee

rustbot has assigned @workingjubilee.
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

@rustbot rustbot added O-unix Operating system: Unix-like 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 Aug 11, 2024
@workingjubilee
Copy link
Member

workingjubilee commented Aug 12, 2024

@devnexen I see that the internal get_path implementation varies significantly based on OS, but are you aware of another Unix OS that would use a different implementation than the current get_mode implementation? It seems everyone uses the same code.

If you are not, I would like to remove the cfg and the "default" implementation and simply use the same code for all OS re: get_mode, and see if it passes in CI. That would also mean we can remove the relevant FIXME.

@workingjubilee
Copy link
Member

@rustbot author

@rustbot rustbot 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 Aug 12, 2024
@devnexen
Copy link
Contributor Author

I have no idea about another exotic unix being different in that regard.

@workingjubilee
Copy link
Member

@devnexen I think I would prefer to demand the "exotic Unix" show themselves.

@workingjubilee
Copy link
Member

Thanks! Let's see what CI says!

@bors r+ rollup=iffy

@bors
Copy link
Collaborator

bors commented Aug 12, 2024

📌 Commit 70e0f69 has been approved by workingjubilee

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 12, 2024
@workingjubilee workingjubilee changed the title std::fs: get_mode implementation for haiku. std::fs: get_mode implementation for all unix Aug 13, 2024
@workingjubilee
Copy link
Member

( aspirationally. )

@bors
Copy link
Collaborator

bors commented Aug 13, 2024

⌛ Testing commit 70e0f69 with merge a2e1d15...

@bors
Copy link
Collaborator

bors commented Aug 13, 2024

☀️ Test successful - checks-actions
Approved by: workingjubilee
Pushing a2e1d15 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 13, 2024
@bors bors merged commit a2e1d15 into rust-lang:master Aug 13, 2024
7 checks passed
@rustbot rustbot added this to the 1.82.0 milestone Aug 13, 2024
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (a2e1d15): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-1.1% [-1.3%, -0.9%] 2
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -1.1% [-1.3%, -0.9%] 2

Max RSS (memory usage)

Results (primary -0.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
2.9% [2.9%, 2.9%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-4.0% [-4.0%, -4.0%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.5% [-4.0%, 2.9%] 2

Cycles

Results (secondary 1.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
1.3% [1.3%, 1.3%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 751.332s -> 753.626s (0.31%)
Artifact size: 341.42 MiB -> 341.40 MiB (-0.00%)

@kadiwa4
Copy link
Contributor

kadiwa4 commented Aug 13, 2024

You silently reverted #128677, was that intentional?

@devnexen
Copy link
Contributor Author

ah no sorry for that

cuviper added a commit to cuviper/rust that referenced this pull request Aug 13, 2024
The update in rust-lang#128677 was accidentally reverted in rust-lang#128962.
@workingjubilee
Copy link
Member

Huh, sorry, didn't notice that. 🙃

bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 16, 2024
Re-update to LLVM 19 rc2

The update in rust-lang#128677 was accidentally reverted in rust-lang#128962.

Fixes rust-lang#129064
r? nikic
rezwanahmedsami pushed a commit to rezwanahmedsami/rust that referenced this pull request Aug 17, 2024
The update in rust-lang#128677 was accidentally reverted in rust-lang#128962.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. O-unix Operating system: Unix-like 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
Development

Successfully merging this pull request may close these issues.

6 participants