-
Notifications
You must be signed in to change notification settings - Fork 40
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
Initial support for tokio #121
base: sync-async
Are you sure you want to change the base?
Changes from all commits
2afb5a1
e0b6be7
975fbec
c056382
8afd567
5f548a3
45f918c
aae1098
a14f6a7
62788e2
933ccc4
57eaa50
4b295d3
dc83532
af5752b
f871fff
951184a
ff97edd
8129f2e
e5af56f
c95da50
2e6053e
794a1d0
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,4 +4,9 @@ fn main() { | |
if var("CARGO_FEATURE_DEFLATE_MINIZ").is_ok() && var("CARGO_FEATURE__ALL_FEATURES").is_err() { | ||
println!("cargo:warning=Feature `deflate-miniz` is deprecated; replace it with `deflate`"); | ||
} | ||
#[cfg(not(any(feature = "sync", feature = "tokio")))] | ||
compile_error!("Missing Required feature"); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Update There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Once the tokio feature is properly working in tests I will update the ci. Currently that is broken. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for letting me know; but if it's going to take longer than about another 3 days, then I'd also greatly appreciate a CI-able update once or twice per week so we could get an idea of how the PR was progressing toward a releasable state where all further work could be deferred to follow-up PRs. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Then I will try doing it this week after I some of my college exams. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @SapryWenInera Have you finished your exams? If not, when do you expect to be able to address the comments on this PR? An ETA would be helpful not only for me, but also for the authors of the other major PRs, given the likelihood of merge conflicts. |
||
|
||
#[cfg(all(feature = "sync", feature = "tokio"))] | ||
compile_error!("The features sync and tokio cannot be used together") | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This restriction may turn out to be a problem for some users. It's possible to import two configurations of a crate twice by renaming one, but then they won't recognize each other's struct types or traits. I can think of two solutions:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm thinking of pushing the old synchronous code in a module of read named sync and then the async code would be in a tokio module, this would avoid conflicts between the codebases, by the end of the week i'm probably gonna push a PR for that since it doesn't require any feature or ci changes. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That sounds good, but will there be a shared-core module as well? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The idea is that the structs and enums can be shared but the actual logic can be separate. This should avoid import conflicts and if there are code changes in the sync part it should not conflict with the async part. Do u think this or the macro one is better? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I favor sharing as much code as possible, based on the Don't Repeat Yourself principle. But the modular design should be compatible with the macro approach: define the macros in the shared core module, and invoke them in the sync and tokio modules. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @SapryWenInera Could you please prioritize this issue for a fix, so that I can run CI on your work in progress and use the results to estimate how much longer this PR will take? |
||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -25,6 +25,7 @@ | |
//! | ZipCrypto deprecated encryption | ✅ | ✅ | | ||
//! | ||
//! | ||
#![cfg_attr(docsrs, feature(doc_auto_cfg))] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why this change? |
||
#![warn(missing_docs)] | ||
#![allow(unexpected_cfgs)] // Needed for cfg(fuzzing) on nightly as of 2024-05-06 | ||
pub use crate::compression::{CompressionMethod, SUPPORTED_COMPRESSION_METHODS}; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,8 +1,13 @@ | ||
//! Types for reading ZIP archives | ||
|
||
/// Module for code with synchronous logic | ||
#[cfg(feature = "sync")] | ||
pub mod sync; | ||
|
||
/// Module for code with asynchronous logic | ||
#[cfg(feature = "tokio")] | ||
pub mod tokio; | ||
|
||
#[cfg(feature = "aes-crypto")] | ||
use crate::{aes::AesReaderValid, types::AesVendorVersion}; | ||
use crate::{crc32::Crc32Reader, types::ZipFileData, zipcrypto::ZipCryptoReaderValid}; | ||
|
@@ -121,7 +126,6 @@ pub(crate) struct CentralDirectoryInfo { | |
mod test { | ||
use crate::ZipArchive; | ||
use std::io::Cursor; | ||
use tempdir::TempDir; | ||
|
||
#[test] | ||
fn invalid_offset() { | ||
|
@@ -316,16 +320,4 @@ mod test { | |
let mut file = reader.by_index(0).unwrap(); | ||
assert_eq!(file.read(&mut decompressed).unwrap(), 12); | ||
} | ||
|
||
#[test] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why are you deleting this? |
||
fn test_is_symlink() -> std::io::Result<()> { | ||
let mut v = Vec::new(); | ||
v.extend_from_slice(include_bytes!("../tests/data/symlink.zip")); | ||
let mut reader = ZipArchive::new(Cursor::new(v)).unwrap(); | ||
assert!(reader.by_index(0).unwrap().is_symlink()); | ||
let tempdir = TempDir::new("test_is_symlink")?; | ||
reader.extract(&tempdir).unwrap(); | ||
assert!(tempdir.path().join("bar").is_symlink()); | ||
Ok(()) | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please make it possible to build with both
sync
andtokio
? To do this, you can invoke the traits with an explicit self parameter, e.g.Read::read_exact(self, buf)
andAsyncRead::read_exact(self, buf)
instead ofself.read_exact(buf)
. Since methods with the same name don't conflict when they're specified in different traits, this should be the only change needed.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, I found a crate that does something similar to this, but with proc macros: https://crates.io/crates/async-generic. Looks like it may still be worth layering a few regular macros on top, for when async-generic functions call other async-generic functions.