-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Rollup of 8 pull requests #65482
Rollup of 8 pull requests #65482
Conversation
Requesting a zero-size allocation is not allowed, return a dangling pointer instead. CC rust-lang#63291 (comment)
ONCE_INIT is deprecated, and so suggesting it as not only being on par with, but before `Once::new` is a bad idea.
Prefer statx on linux if available This PR make `metadata`-related functions try to invoke `statx` first on Linux if available, making `std::fs::Metadata::created` work on Linux with `statx` supported. It follows the discussion in rust-lang#61386 , and will fix rust-lang#59743 The implementation of this PR is simply converting `struct statx` into `struct stat64` with extra fields for `btime` if `statx` succeeds, since other fields are not currently used. --- I also did a separated benchmark for `fs::metadata`, `stat64`, `statx`, and `statx` with conversion to `stat64`. It shows that `statx` with conversion is even more faster than pure `statx`. I think it's due to `sizeof stat64 == 114` but `sizeof statx == 256`. Anyway, the bare implementation of `statx` with conversion is only about 0.2% slower than the original impl (`stat64`-family). With heap-allocation counted (~8.5% of total cost), the difference between `stat` and `statx` (with or without conversion) is just nothing. Therefore, I think it is not urgent to use bare `struct statx` as underlying representation now. There is no need to break `std::os::linux::fs::MetadataExt::as_raw_stat` (rust-lang#61386 (comment)) [Separated bare benchmarks](https://gist.github.com/oxalica/c4073ecb202c599fe41b7f15f86dc79c): ``` metadata_ok time: [529.41 ns 529.77 ns 530.19 ns] metadata_err time: [538.71 ns 539.39 ns 540.35 ns] stat64_ok time: [484.32 ns 484.53 ns 484.75 ns] stat64_err time: [481.77 ns 482.00 ns 482.24 ns] statx_ok time: [488.07 ns 488.35 ns 488.62 ns] statx_err time: [487.74 ns 488.00 ns 488.27 ns] statx_cvt_ok time: [485.05 ns 485.28 ns 485.53 ns] statx_cvt_err time: [485.23 ns 485.45 ns 485.67 ns] ``` r? @alexcrichton
Fix zero-size uninitialized boxes Requesting a zero-size allocation is not allowed, return a dangling pointer instead. CC rust-lang#63291 (comment)
InterpCx: make memory field public I made this field private forever ago because I thought sealing things might be nice. But with the `memory_mut` getter it doesn't actually seal anything, and it's not like we need to invalidate caches on writes to memory or so. And moreover, having to use the getters leads to some annoying borrow checking interactions. So, let's just make it public (again). r? @oli-obk
…-E0575, r=kinnison Add long error explanation for E0575 Part of rust-lang#61137.
Don't recommend ONCE_INIT in std::sync::Once ONCE_INIT is deprecated, and so suggesting it as not only being on par with, but before `Once::new` is a bad idea.
Move syntax::ext to a syntax_expand and refactor some attribute logic Part of rust-lang#65324. r? @petrochenkov
add example for type_name So users of this function could at least expect what its output for current compiler version.
fmt::Write is about string slices, not byte slices No idea why the docs talk about bytes, maybe a copy-paste error?
@bors r+ p=8 rollup=never |
📌 Commit 940ae78 has been approved by |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Successful merges:
Failed merges:
r? @ghost