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

Rollup of 9 pull requests #65449

Closed
wants to merge 23 commits into from
Closed

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Oct 15, 2019

Successful merges:

Failed merges:

r? @ghost

nikomatsakis and others added 23 commits October 11, 2019 16:59
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
@Centril
Copy link
Contributor Author

Centril commented Oct 15, 2019

@bors r+ p=9 rollup=never

@bors
Copy link
Contributor

bors commented Oct 15, 2019

📌 Commit 9ce03a6 has been approved by Centril

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 15, 2019
@bors
Copy link
Contributor

bors commented Oct 15, 2019

⌛ Testing commit 9ce03a6 with merge 17e36d8c4ae1f540675630e89d697dfff9fcdb1b...

@rust-highfive
Copy link
Collaborator

The job dist-various-2 of your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
2019-10-15T20:48:14.0158246Z [RUSTC-TIMING] backtrace test:false 0.527
2019-10-15T20:48:16.8733742Z error[E0308]: mismatched types
2019-10-15T20:48:16.8735408Z    --> src/libstd/sys/unix/fs.rs:151:38
2019-10-15T20:48:16.8736293Z     |
2019-10-15T20:48:16.8736963Z 151 |                 stat.st_atime_nsec = buf.stx_atime.tv_nsec as libc::c_long;
2019-10-15T20:48:16.8738226Z     |                                      |
2019-10-15T20:48:16.8738835Z     |                                      expected i64, found i32
2019-10-15T20:48:16.8738835Z     |                                      expected i64, found i32
2019-10-15T20:48:16.8740335Z     |                                      help: you can convert an `i32` to `i64`: `(buf.stx_atime.tv_nsec as libc::c_long).into()`
2019-10-15T20:48:16.8759519Z error[E0308]: mismatched types
2019-10-15T20:48:16.8760367Z    --> src/libstd/sys/unix/fs.rs:153:38
2019-10-15T20:48:16.8764606Z     |
2019-10-15T20:48:16.8764606Z     |
2019-10-15T20:48:16.8765401Z 153 |                 stat.st_mtime_nsec = buf.stx_mtime.tv_nsec as libc::c_long;
2019-10-15T20:48:16.8766626Z     |                                      |
2019-10-15T20:48:16.8767260Z     |                                      expected i64, found i32
2019-10-15T20:48:16.8767260Z     |                                      expected i64, found i32
2019-10-15T20:48:16.8767929Z     |                                      help: you can convert an `i32` to `i64`: `(buf.stx_mtime.tv_nsec as libc::c_long).into()`
2019-10-15T20:48:16.8777950Z error[E0308]: mismatched types
2019-10-15T20:48:16.8779791Z    --> src/libstd/sys/unix/fs.rs:155:38
2019-10-15T20:48:16.8781153Z     |
2019-10-15T20:48:16.8781153Z     |
2019-10-15T20:48:16.8782927Z 155 |                 stat.st_ctime_nsec = buf.stx_ctime.tv_nsec as libc::c_long;
2019-10-15T20:48:16.8786301Z     |                                      |
2019-10-15T20:48:16.8787918Z     |                                      expected i64, found i32
2019-10-15T20:48:16.8787918Z     |                                      expected i64, found i32
2019-10-15T20:48:16.8789726Z     |                                      help: you can convert an `i32` to `i64`: `(buf.stx_ctime.tv_nsec as libc::c_long).into()`
2019-10-15T20:48:16.9252462Z error[E0308]: mismatched types
2019-10-15T20:48:16.9254714Z    --> src/libstd/sys/unix/fs.rs:311:34
2019-10-15T20:48:16.9256413Z     |
2019-10-15T20:48:16.9256413Z     |
2019-10-15T20:48:16.9258092Z 311 |                         tv_nsec: ext.stx_btime.tv_nsec as libc::c_long,
2019-10-15T20:48:16.9260382Z     |                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected i64, found i32
2019-10-15T20:48:17.3127402Z error: aborting due to 4 previous errors
2019-10-15T20:48:17.3127537Z 
2019-10-15T20:48:17.3127911Z For more information about this error, try `rustc --explain E0308`.
2019-10-15T20:48:17.3815704Z [RUSTC-TIMING] std test:false 3.361
---
2019-10-15T20:48:17.3951184Z == clock drift check ==
2019-10-15T20:48:17.4001534Z   local time: Tue Oct 15 20:48:17 UTC 2019
2019-10-15T20:48:17.5444193Z   network time: Tue, 15 Oct 2019 20:48:17 GMT
2019-10-15T20:48:17.5445628Z == end clock drift check ==
2019-10-15T20:48:19.7576259Z ##[error]Bash exited with code '1'.
2019-10-15T20:48:19.7616879Z ##[section]Starting: Upload CPU usage statistics
2019-10-15T20:48:19.7625552Z ==============================================================================
2019-10-15T20:48:19.7625898Z Task         : Bash
2019-10-15T20:48:19.7625999Z Description  : Run a Bash script on macOS, Linux, or Windows

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 @TimNN. (Feature Requests)

@bors
Copy link
Contributor

bors commented Oct 15, 2019

💔 Test failed - checks-azure

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 15, 2019
@Centril Centril closed this Oct 15, 2019
@Centril Centril deleted the rollup-c9fwcu8 branch October 15, 2019 20:53
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ThinLTO and -o compiler option can lead to duplicate object file inclusion in staticlib
10 participants