Nemo157

Warn on any inconsistency in workspace and package resolver

3

If the workspace and package specify or default to different resolver versions then this will cause inconsistencies in build behavior between a development build within the workspace and the published...

Tests with non-default required-features cause build failures

2

Example recent build log: https://crater-reports.s3.amazonaws.com/pr-66919/master%234007d4ef26eab44bdabc2b7574d032152264d3ad/reg/async-compression-0.1.0/log.txt All the integration tests in this crate use `required-features` for non-default features as the crate is empty without any features active. It appears Crater attempts...

For [`async-compression`](https://github.com/Nemo157/async-compression) the majority of the API provided by the crate is disabled by default to reduce build time for dependencies. Given that, at the moment when this is built...

Distro upgrade policy

9

Currently it's documented that the images are built using Ubuntu 20.04, which is the most recent Ubuntu LTS. It would be good to have the upgrade policy for this clarified,...

Make nightly build test against updated dependencies

1

#122 should have been picked up automatically when zstd 0.8.2 was released; there should be another job that runs nightly (but using the stable compiler), updates all dependencies, then runs...

Remove support for tokio 0.2 and 0.3

3

I have checked the index using `rg -IN 'async-compression' | jq -r '"\(.name) \(.vers): \(.deps[] | select(.name == "async-compression") | .features | join(", "))"'` and there are only 2 crates...

Decoder might block if there is data remaining to be flushed from the codec and the stream blocks

2

See https://github.com/gyscos/zstd-rs/issues/119, I'm pretty sure the local `bufread::Decoder` implementations suffer from this same issue. My first attempt at writing a test case failed to fail though.

So many blockers though 😭

Benchmarks!

2

Should be pretty easy to throw together some benchmarks comparing the different async variants against their synchronous counterparts to see how much overhead the async state machines introduce.

If a user attempts a vectored read/write it should be possible to more efficiently process this than the default implementation provided in `futures-io`.