Skip to content
This repository was archived by the owner on Feb 28, 2023. It is now read-only.

Comments

futures migration 0.1 -> 0.3#31

Closed
drahnr wants to merge 141 commits intomasterfrom
bernhard-futures-migration
Closed

futures migration 0.1 -> 0.3#31
drahnr wants to merge 141 commits intomasterfrom
bernhard-futures-migration

Conversation

@drahnr
Copy link
Contributor

@drahnr drahnr commented Jan 31, 2021

The giant PR with eventually atomic commits, providing a step by step migration with individually compilable commits.

  • Application with default features builds
  • Application with non-default features builds
  • Tests pass and work
  • Rework commits into atomic changes which compile (wanted for upstream)

drahnr and others added 30 commits November 12, 2020 14:01
* change (CI): initial CI

* change (CI): initial CI

* change (CI): add clippy and allow failure
PRs labelled `autorebase:opt-in` will be rebased automatically after updates in `master`.
In order to avoid timestamp presence in static lib files,
making them non-deterministic.

alexcrichton/cc-rs@555e773
mozilla/sccache#197
Xanewok and others added 23 commits March 27, 2021 23:55
* Fix some types when not using dist-client feature

* Pull required features for Tokio 0.2

This fixes a `--no-default-features` build since other dependencies
incidentally pulled the relevant features themselves.

* Fix compilation when using only azure feature

* Fix compilation when using only dist-server feature
Most notably prefer std::future::Future over futures::Future since the
std variant is here to stay
Let's stick to the upstream version. We seem to only care about starting
and keeping the child server process alive until the end of the
function, prefer the std variant for simplicity and to avoid footguns
such as `Runtime::enter` that we had to use here.
The async `get_dist_status` called `get_status` that was locally
blocking in a freshly created `Runtime`. Instead, use the already
present `Runtime` instead creating it from scratch and mark `get_status`
appropriately as async.
The only reason that's there is because the compiler is too conservative
and treats borrows as alive longer than they actually are (even with
explicit `drop`). Work around that by creating an owned future instead,
returned from the `resolve_proxied_executable`.

It's worth noting that `async_trait` returns a `Pin<Box>`ed future with
the 'async lifetime, where we have &'async self as the method receiver.
Because of this, we manually construct the future ourselves with the
'static lifetime.
@drahnr
Copy link
Contributor Author

drahnr commented May 2, 2021

Superseeded by #68

@drahnr drahnr closed this May 2, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants