This repository has been archived by the owner on Oct 23, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 163
fix: compilation error when used as a dependency #470
Merged
Merged
Conversation
This file contains 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
Pasted the error in a gist: https://gist.github.com/koivunej/a57c843758b01bd82e9883d9c997e857 |
8 tasks
afa0e47
to
159678a
Compare
koivunej
commented
Aug 3, 2021
koivunej
commented
Aug 3, 2021
koivunej
commented
Aug 3, 2021
20480ff
to
bfe3626
Compare
Thought of keeping the back and forth of "ci: add dependent crate" to remind what went down, but will probably just clean it up if it now builds ok. |
bfe3626
to
4b730ee
Compare
Finally the expansions between async-trait versions: https://gist.github.com/koivunej/cbcaae52b7242a73419ef62e4c606bd7 |
lgtm |
see comments in rs-ipfs#458. it is unknown why this is needed but it does work away of the compiler error. it was later found out by bisecting Cargo.lock that this is caused by async-trait 0.1.42 => 0.1.43 upgrade, but it's very unclear why this would be caused by the only PR in that release.
either required the use of the empty stream, which probably was an additional extra type which is now worked away with.
this was kept around for ipfs-http but it lead to problems using the ipfs crate as a dependency.
hopefully this will catch if we go out of sync with some upstream crates.
this was not set originally because probably mpart-async sets it, but the code in `ipfs` assumed `std` feature was enabled and thus the from conversion was accessible.
4b730ee
to
2ee1463
Compare
Cancelling, letting bors handle. bors r+ |
bors bot
added a commit
that referenced
this pull request
Aug 4, 2021
470: fix: compilation error when used as a dependency r=koivunej a=koivunej Fixes the issue reported in [comment of #458](#458 (comment)) that whenever dependent on, even without any code calling `ipfs`, there is a build failure. This PR: - removes top-level Cargo.lock now that I've learned why it's not good to keep around - adds weekly scheduled build - moves the `FsBlockStore::list` method body over to `FsBlockStore::list0` outside the `#[async_trait] impl BlockStore for FsBlockStore { ... }` where it does get the correct lifetimes inferred for the returned boxed future The original compilation failure was caused by `async-trait` 0.1.42 => 0.1.43 upgrade deduced by bisecting Cargo.lock changes. It's still unknown why does the moved version work, but there are probably a lot of subleties to the code generated by `async-trait`. I don't yet know if this warrants any upstream bug reports; most likely not, we were stuck on a quite old version and many crates now work with it. Co-authored-by: Joonas Koivunen <joonas.koivunen@gmail.com>
Hmm.... Wonder what's happening. bors ping |
pong |
Cannot find any related bug reports... bors r+ |
Aah found it for the earlier merge from the logs, it was a crash:
|
Build succeeded: |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Fixes the issue reported in comment of #458 that whenever dependent on, even without any code calling
ipfs
, there is a build failure. This PR:FsBlockStore::list
method body over toFsBlockStore::list0
outside the#[async_trait] impl BlockStore for FsBlockStore { ... }
where it does get the correct lifetimes inferred for the returned boxed futureThe original compilation failure was caused by
async-trait
0.1.42 => 0.1.43 upgrade deduced by bisecting Cargo.lock changes. It's still unknown why does the moved version work, but there are probably a lot of subleties to the code generated byasync-trait
. I don't yet know if this warrants any upstream bug reports; most likely not, we were stuck on a quite old version and many crates now work with it.