The pointer returned by `BackingStore::data` might be null if the
backing store has zero length, but the return type `*mut c_void` does
not force the user to consider this case. This change makes the return
type `Option<NonNull<c_void>>`, which is semantically equivalent, but
which forces users of the API to handle the `None` case.
This is a breaking API change.
This avoids constant rebuilds when alternating between running
$ cargo build
$ cargo run <something that runs cargo build>
Since the second command will see these environment variables set
during the logic deciding if build.rs should be rerun or not.
Since these are cargo specific variables, hopefully cargo already does
the right thing without our help.
In addition to the problem described in issue #378, we noticed link
error when updating rusty_v8 without doing a clean build. As far as I
can tell, there were two potential bugs:
* Cargo not being informed that it should run build.rs when
CARGO_PKG_VERSION changed.
* Even if build.rs was rerun, it would not download a new package. It
seems that build.rs should either verify that the right package was
downloaded or should just trust cargo to not rerun it when not
needed.
Fixes: #378
For zero-size `BackingStore`s, it seems like `BackingStore::data` always
returns a null pointer. The `Deref` impl for `BackingStore` called
`std::slice::from_raw_parts` on that pointer, even though it is UB to
call that function on a null pointer even for empty slices. This change
fixes that by obtaining a valid pointer from `NonNull::dangling()` if
the original is null.
Reported in
https://github.com/denoland/rusty_v8/issues/711#issuecomment-950637136.
Best case, it produces serialized output that cannot be deserialized.
Worst case, it hits this assert in V8:
# Fatal error in v8::FromJust
# Maybe value is Nothing.
