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 5 pull requests #99550

Closed
wants to merge 16 commits into from
Closed

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

joboet and others added 16 commits June 30, 2022 11:48
These merged in rust-lang#97437 for 1.64.0, apart from the main `io_safety`
feature that stabilized in 1.63.0.
Fix type error

Fix continue_value doc comment
std: use futex-based locks on Fuchsia

This switches `Condvar` and `RwLock` to the futex-based implementation currently used on Linux and some BSDs. Additionally, `Mutex` now has its own, priority-inheriting implementation based on the mutex in Fuchsia's `libsync`. It differs from the original in that it deadlocks when reentrant locking is detected, as leaking a `MutexGuard` could lead to the same thread id being used in another thread, which would then panic with a nonsensical error message, which definitely is not expected.

`@rustbot` ping fuchsia
r? `@m-ou-se`
…t-generic-suffixes, r=petrochenkov

feat: omit suffixes in const generics (e.g. `1_i32`)

Closes rust-lang#99255
…-item, r=lcnr

Do not resolve associated const when there is no provided value

Fixes rust-lang#98629, since now we just delay a bug when we're not able to evaluate a const item due to the value not actually being provided by anything. This means compilation proceeds forward to where the "missing item in impl" error is emitted.

----

The root issue here is that when we're looking for the defining `LeafDef` in `resolve_associated_item`, we end up getting the trait's AssocItem instead of the impl's AssocItem (which does not exist). This resolution "succeeds" even if the trait's item has no default value, and then since this item has no value to evaluate, it turns into a const eval error.

This root issue becomes problematic (as in rust-lang#98629) when this const eval error happens in wfcheck (for example, due to normalizing the param-env of something that references this const). Since this happens sooner than the check that an impl actually provides all of the items that a trait requires (which happens during later typecheck), we end up aborting compilation early with only this un-informative message.

I'm not exactly sure _why_ this bug arises due to rust-lang#96591 -- perhaps valtrees are evaluated more eagerly than in the old system?

r? ```@oli-obk``` or ```@lcnr``` since y'all are familiar with const eval and reviewed rust-lang#96591, though feel free to reassign.

This is a regression from stable to beta, so I would be open to considering this for beta backport. It seems correct to me, especially given the improvements in the other UI tests this PR touches, but may have some side-effects that I'm unaware of...?
…inators, r=scottmcm

Add map_continue and continue_value combinators to ControlFlow

As suggested in this comment: rust-lang#75744 (comment)

Related tracking issue: rust-lang#75744

r? ```@scottmcm```
Fix the stable version of `AsFd for Arc<T>` and `Box<T>`

These merged in rust-lang#97437 for 1.64.0, apart from the main `io_safety`
feature that stabilized in 1.63.0.
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jul 21, 2022
@Dylan-DPC
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Jul 21, 2022

📌 Commit 3bb74ab has been approved by Dylan-DPC

It is now in the queue for this repository.

@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 Jul 21, 2022
@bors
Copy link
Contributor

bors commented Jul 21, 2022

⌛ Testing commit 3bb74ab with merge f49cc7dabbe39aecb3b2e0d35ff87a596e4f001a...

@bors
Copy link
Contributor

bors commented Jul 21, 2022

💔 Test failed - checks-actions

@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 Jul 21, 2022
@rust-log-analyzer
Copy link
Collaborator

The job dist-various-2 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[RUSTC-TIMING] addr2line test:false 0.543
[RUSTC-TIMING] core test:false 31.724
[RUSTC-TIMING] gimli test:false 5.569
[RUSTC-TIMING] object test:false 5.824
error[E0252]: the name `ZX_TIME_INFINITE` is defined multiple times
  --> library/std/src/sys/unix/locks/fuchsia_mutex.rs:47:23
   |
47 |     ZX_TIME_INFINITE, ZX_TIME_INFINITE,
   |     ----------------  ^^^^^^^^^^^^^^^^-
   |     |                 |
   |     |                 `ZX_TIME_INFINITE` reimported here
   |     |                 help: remove unnecessary import
   |     previous import of the value `ZX_TIME_INFINITE` here
   |
   = note: `ZX_TIME_INFINITE` must be defined only once in the value namespace of this module

error: unused import: `ZX_TIME_INFINITE`
  --> library/std/src/sys/unix/locks/fuchsia_mutex.rs:47:23
   |
47 |     ZX_TIME_INFINITE, ZX_TIME_INFINITE,
   |
   |
   = note: `-D unused-imports` implied by `-D warnings`
For more information about this error, try `rustc --explain E0252`.
[RUSTC-TIMING] std test:false 2.890
error: could not compile `std` due to 2 previous errors
Build completed unsuccessfully in 0:13:30

@Dylan-DPC Dylan-DPC closed this Jul 21, 2022
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. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants