vigna / epserde-rs Goto Github PK

View Code? Open in Web Editor NEW

130.0 130.0 5.0 573 KB

An ε-copy serialization/deserialization framework for Rust

Rust 100.00%

epserde-rs's People

Contributors

Stargazers

Watchers

Forkers

zacchiro progval djkoloski

epserde-rs's Issues

Detect, and possibly refuse, repr(u64) and similar

repr(u64) causes a variation in alignment that confuses ε-serde, leading to errors. We should either handle it, or refuse it.

Internal type variables don't work

The derive macros currently don't work with

struct Data<A> {
    a: Vec<A>,
    test: isize,
}

You need at least

struct Data<A: DeepCopy> {
    a: Vec<A>,
    test: isize,
}

to explain how to behave with Vec, but then there's a lifetime problem and if you try

struct Data<A> {
    a: Vec<A>,
    test: isize,
}

You get "higher-ranked lifetime error".

Should ZeroCopy depend on Copy?

The docs say to be ZeroCopy you need to be a copy type, so that would make a lot of sense.

We should check that a type implements ZeroCopy consistently upon serialization and deserialization

Traits and types are a bit mixed in source files

Clarify schema order

The documentation still says you need to sort it.

Consider using a ReadNotStd + ReadWithCnt in deserialize_full_copy

Currently, deserialize_full_copy takes a slice of u8 as deserialize_eps_copy. This however is not necessary, as a full copy can be obtained reading from a file.

We could define a ReadNoStd parallel to WriteNoStd and a ReadWithCnt. deserialize_full_copy would take a ReadWithCnt and deserialize from there. When passing from ε to full, one would wrap the current Cursor with a suitable ReadWithCnt. In fact, Cursor might directly implement ReadWithCnt, which would make passing from ε to full trivial.

At that point instead of just load we would have load_eps, doing what currently load does, and load_full, acting like a standard deserialization mechanism.

The disadvantage is that we would have to write a few deserialize_full_copy in ReadWithCnt style, instead of delegating or reading from a Cursor.

Handle tuple types in the derive macro

Remove dependency from anyhow in MemCase

Review checks and warnings

FullCopy is still not a good name

We should check that zero-copy types are Copy

`new_aligned_cursor` is unsound and causes UB on reallocation or drop

Repro:

$ cargo +nightly miri test --test test_generics

Output:

running 2 tests
error: Undefined Behavior: incorrect layout on deallocation: alloc27687 has size 1024 and alignment 128, but gave size 1024 and alignment 1
   --> $DIR\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\alloc\src\alloc.rs:117:14
    |
117 |     unsafe { __rust_dealloc(ptr, layout.size(), layout.align()) }
    |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ incorrect layout on deallocation: alloc27687 has size 1024 and alignment 128, but gave size 1024 and alignment 1
    |
    = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
    = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
    = note: BACKTRACE:
    = note: inside `std::alloc::dealloc` at $DIR\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\alloc\src\alloc.rs:117:14: 117:64
    = note: inside `<std::alloc::Global as std::alloc::Allocator>::deallocate` at $DIR\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\alloc\src\alloc.rs:254:22: 254:51
    = note: inside `<alloc::raw_vec::RawVec<u8> as std::ops::Drop>::drop` at $DIR\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\alloc\src\raw_vec.rs:505:22: 505:56
    = note: inside `std::ptr::drop_in_place::<alloc::raw_vec::RawVec<u8>> - shim(Some(alloc::raw_vec::RawVec<u8>))` at $DIR\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\ptr\mod.rs:498:1: 498:56
    = note: inside `std::ptr::drop_in_place::<std::vec::Vec<u8>> - shim(Some(std::vec::Vec<u8>))` at $DIR\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\ptr\mod.rs:498:1: 498:56
note: inside `test_inner_param_eps`
   --> epserde\tests\test_generics.rs:70:1
    |
70  | }
    | ^
note: inside closure
   --> epserde\tests\test_generics.rs:50:26
    |
49  | #[test]
    | ------- in this procedural macro expansion
50  | fn test_inner_param_eps() {
    |                          ^
    = note: this error originates in the attribute macro `test` (in Nightly builds, run with -Z macro-backtrace for more info)

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error

It is UB to create a std::vec::Vec using from_raw_parts with a memory allocation that has an alignment other than align_of::<T>(). Here, the alignment must be 1 because u8 has an alignment of 1. However, the Vec is being created with an alignment of 16. This can cause problems with memory allocators that use the alignment during deallocation.

Extend and rationalize MemCase's flags

PhantomData should be, really, anything

We should find an easy way for the user to pass parameters for a PhantomData without any requirement (presently you need TypeHash and ReprHash).

We could eliminate all requirement and use the system type name in TypeHash, but that's a bit dangerous because we lose control of the value.

Alternatively, we can provide a macro that generates a newtype (possibly trait-based) which implements ReprHash and TypeHash without recursing into the content.

use epserde::*;

#[derive(Serialize, Deserialize, TypeHash, Debug, PartialEq, Eq, Default, Clone)]
/// Random struct we will use to test the nested serialization and deserialization.
struct Data<A> {
    a: Vec<A>,
    test: isize,
}

gives a weird error:

error[E0107]: struct takes 1 generic argument but 0 generic arguments were supplied
  --> epserde/examples/vec_vec.rs:11:8
   |
11 | struct Data<A> {
   |        ^^^^ expected 1 generic argument
   |
note: struct defined here, with 1 generic parameter: `A`
  --> epserde/examples/vec_vec.rs:11:8
   |
11 | struct Data<A> {
   |        ^^^^ -
help: add missing generic argument
   |
9  | #[derive(Serialize, DAeserialize, TypeHash, Debug, PartialEq, Eq, Default, Clone)]
   |

Note that DAeserialize. I guess some problem in the derived code.

(Incidentally, I'm not even sure what would be the expected behavior, but let's start from the syntax error...)