Rollup of 9 pull requests #65449
Closed
Rollup of 9 pull requests #65449
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
In particular, we sometimes cannot if there is an earlier error.
…to identify Rust generated object files.
add test to for the fix add descriptive text for the fix simplified code logics update descriptive comments update to cope with the tidyness requirement merged commit suggestions Co-Authored-By: varkor <github@varkor.com> truncated redundant comments update to cope with tidy-check
Also move {run-fail -> ui}/never_type 
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
…eturn-ice, r=cramertj don't assume we can *always* find a return type hint in async fn In particular, we sometimes cannot if there is an earlier error. Fixes rust-lang#65159 r? @cramertj, who reviewed the original PR
Fix suggestion to constrain trait for method to be found Fix rust-lang#65044.
Try fix incorrect "explicit lifetime name needed" This pr is trying to fixes rust-lang#65285 .
…drop, r=eddyb Return `false` from `needs_drop` for all zero-sized arrays. Resolves rust-lang#65348. This changes the result of the `needs_drop` query from `true` to `false` for types such as `[Box<i32>; 0]`. I believe this change to be sound because a zero-sized array can never actually hold a value. This is an elegant way of resolving rust-lang#65348 and rust-lang#64945, but obviously it has much broader implications.
…g-docs, r=alexcrichton Add troubleshooting section to PGO chapter in rustc book. - Adds a note about using `-pgo-warn-missing-function` in order to spot mistakes in PGO setup. - Mentions cargo symbol name issue fixed in 1.39. Nominating for backport. r? @alexcrichton
…=alexcrichton Fix rust-lang#64153 This PR changes how the compiler detects if an object file from an upstream crate is a Rust object file or not. Instead of checking if the name starts with the crate name and ends with `.o` (which is not always the case, as described in rust-lang#64153), it now just checks if the filename ends with `.rcgu.o`. This fixes rust-lang#64153. However, ideally we'd clean up the code around filename generation some more. Then this check could be made more robust. r? @alexcrichton
Organize `never_type` tests Extracted from rust-lang#65355. This just moves some tests around to make things better categorized. r? @varkor
…Simulacrum Implement AsRef<[T]> for List<T> r? @Mark-Simulacrum
| @bors r+ p=9 rollup=never |
| 📌 Commit 9ce03a6 has been approved by |
bors added the S-waiting-on-bors | ⌛ Testing commit 9ce03a6 with merge 17e36d8c4ae1f540675630e89d697dfff9fcdb1b... |
| 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 |
| 💔 Test failed - checks-azure |
bors added S-waiting-on-review 
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
Successful merges:
falsefromneeds_dropfor all zero-sized arrays. #65389 (Returnfalsefromneeds_dropfor all zero-sized arrays.)-ocompiler option can lead to duplicate object file inclusion in staticlib #64153)never_typetests #65438 (Organizenever_typetests)Failed merges:
r? @ghost