The `cargo fmt` preupload check will be replaced with a rustfmt check
that does not require projects to opt in.
This reverts commit 35bac991e6.
BUG=chromium:908640
TEST=`repo upload`
Change-Id: I08f081ef7b889542a6d95fe3f13cdc480759207c
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1376070
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
In order to properly send dmabufs over the wayland protocol, accurate
buffer metadata is needed in the guest. This change plumbs information
from minigbm allocations to the guest using a virtio-gpu response.
BUG=875998
TEST=wayland-simple-egl
Change-Id: I5c80d539bc7757c302ad7adf56f5d3b011304617
Reviewed-on: https://chromium-review.googlesource.com/1227054
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: David Riley <davidriley@chromium.org>
We updated the production toolchain from 1.30 to 1.31 in CL:1366446.
This CL does the same upgrade for the local developer toolchain and
Kokoro.
The relevant changes are in rust-toolchain and kokoro/Dockerfile.
The rest are from rustfmt.
TEST=cargo fmt --all -- --check
TEST=as described in kokoro/README.md
Change-Id: I3b4913f3e237baa36c664b4953be360c09efffd4
Reviewed-on: https://chromium-review.googlesource.com/1374376
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This change uses the resource bridge between virtio-gpu and virtio-cpu
to send resources over the host wayland connection that originated from
the virtio-gpu device. This will help support gpu accelerated wayland
surfaces.
BUG=chromium:875998
TEST=wayland-simple-egl
Change-Id: I3340ecef438779be5cb3643b2de8bb8c33097d75
Reviewed-on: https://chromium-review.googlesource.com/1182793
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Add the minimal amount of functionality needed for audio threads that
need to run with real time priority.
Change-Id: I7052e0f2ba6b9179229fc4568b332952ee32f076
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1366542
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
This CL removes 300 lines of parsing code and 200 lines of tests of
parsing code by using the parsers provided by Syn, which we already use
in implementing our other custom derives.
TEST=cargo test poll_token_derive
TEST=cargo check crosvm
Change-Id: Ie2743b1bbb1b374326f9845fc37fc578b178c53d
Reviewed-on: https://chromium-review.googlesource.com/1365112
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This depends on the `assertions` crate added in CL:1366819.
`const_assert!(boolean expression)` is a compile-time assertion that
fails to compile if the expression is false.
TEST=`cargo check` each of the modified crates
Change-Id: I559884baf2275b1b506619693cd100a4ffc8adcd
Reviewed-on: https://chromium-review.googlesource.com/1368364
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
A static assertion is particularly appropriate when unsafe code relies
on two types to have the same size, or on some type to have a particular
size. This is a pattern I observed in USB code, for example:
ff7068402e/devices/src/usb/xhci/xhci_abi_schema.rs (522)
EXAMPLE:
extern crate assertions;
use assertions::const_assert;
fn main() {
const_assert!(std::mem::size_of::<String>() == 24);
}
EXAMPLE THAT FAILS TO COMPILE:
extern crate assertions;
use assertions::const_assert;
fn main() {
// fails to compile:
const_assert!(std::mem::size_of::<String>() == 8);
}
FAILURE LOOKS LIKE:
error[E0271]: type mismatch resolving `<[(); 0] as assertions::Expr>::Value == assertions::True`
--> src/main.rs:5:5
|
5 | const_assert!(std::mem::size_of::<String>() == 8);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `assertions::True`, found struct `assertions::False`
TEST=`cargo test` the new crate
Change-Id: I6abe36d5a6a4bd4acb1a02e3aa7c1ece5357f007
Reviewed-on: https://chromium-review.googlesource.com/1366819
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This CL adds a procedural macro to generate functions for converting a
primitive integer into the corresponding variant of an enum.
Loosely based on https://docs.rs/enum-primitive-derive but implemented
against a newer version of Syn and without the dependency on num-traits.
The generated function is named `n` and has the following signature:
impl YourEnum {
pub fn n(value: Repr) -> Option<Self>;
}
where `Repr` is an integer type of the right size as described in more
detail below.
EXAMPLE
extern crate enumn;
#[derive(PartialEq, Debug, enumn::N)]
enum Status {
LegendaryTriumph,
QualifiedSuccess,
FortuitousRevival,
IndeterminateStalemate,
RecoverableSetback,
DireMisadventure,
AbjectFailure,
}
fn main() {
let s = Status::n(1);
assert_eq!(s, Some(Status::QualifiedSuccess));
let s = Status::n(9);
assert_eq!(s, None);
}
SIGNATURE
The generated signature depends on whether the enum has a `#[repr(..)]`
attribute. If a `repr` is specified, the input to `n` will be required
to be of that type.
#[derive(enumn::N)]
#[repr(u8)]
enum E {
/* ... */
}
// expands to:
impl E {
pub fn n(value: u8) -> Option<Self> {
/* ... */
}
}
On the other hand if no `repr` is specified then we get a signature that
is generic over a variety of possible types.
impl E {
pub fn n<REPR: Into<i64>>(value: REPR) -> Option<Self> {
/* ... */
}
}
DISCRIMINANTS
The conversion respects explictly specified enum discriminants. Consider
this enum:
#[derive(enumn::N)]
enum Letter {
A = 65,
B = 66,
}
Here `Letter::n(65)` would return `Some(Letter::A)`.
TEST=`cargo test` against the new crate
Change-Id: I4286a816828c83507b35185fe497455ee30ae9e8
Reviewed-on: https://chromium-review.googlesource.com/1365114
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This CL adds a crate `sync` containing a type sync::Mutex which wraps
the standard library Mutex and mirrors the same methods, except that
they panic where the standard library would return a PoisonError. This
API codifies our error handling strategy around poisoned mutexes in
crosvm.
- Crosvm releases are built with panic=abort so poisoning never occurs.
A panic while a mutex is held (or ever) takes down the entire process.
Thus we would like for code not to have to consider the possibility of
poison.
- We could ask developers to always write `.lock().unwrap()` on a
standard library mutex. However, we would like to stigmatize the use
of unwrap. It is confusing to permit unwrap but only on mutex lock
results. During code review it may not always be obvious whether a
particular unwrap is unwrapping a mutex lock result or a different
error that should be handled in a more principled way.
Developers should feel free to use sync::Mutex anywhere in crosvm that
they would otherwise be using std::sync::Mutex.
TEST=boot linux
Change-Id: I9727b6f8fee439edb4a8d52cf19d59acf04d990f
Reviewed-on: https://chromium-review.googlesource.com/1359923
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
During runtime, we track unreferenced clusters (via unref_clusters and
avail_clusters) and reuse them before extending the disk image.
However, across boots, we did not previously recover the list of
unreferenced clusters, so the disk file could grow beyond the range that
the reference table count represent. This patch adds a boot-time scan
for all unreferenced clusters so that they get reused.
BUG=chromium:899273
TEST=Boot with qcow2 image, fill the disk with dd, delete the dd'd file,
refill with dd, and so on, repeatedly. Ensure that the disk image does
not grow beyond the expected max size and that no clusters beyond the
size of the refcount table are used.
Change-Id: Idd21b08bb4c55b8244e7ecaccafc4ccc46b7b17a
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1327822
Reviewed-by: Dylan Reid <dgreid@chromium.org>
I noticed this questionable loop that never loops in CL:1357700. Purely
guessing as to what it was supposed to do -- I have not tested this
codepath.
TEST=cargo check
Change-Id: I4560b80f080112a78adf440a663341f4fb0f1070
Reviewed-on: https://chromium-review.googlesource.com/1359010
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
The `while sig_ok` in the original code suggests that `sig_ok` would be mutated
by the loop body, but it was not. Really `while sig_ok` was being used to mean
`if sig_ok { loop { ... } }`, with breaks to exit the loop body.
I replaced `while sig_ok` with `if sig_ok` containing `loop`. Since this is an
extra layer of indentation, I removed two layers of indentation by flattening a
a nested match so the new code is overall less indented than before.
Clippy flags such loops in which the loop condition never changes as high
confidence of being a bug or at least misleading:
https://rust-lang.github.io/rust-clippy/master/index.html#while_immutable_condition
TEST=run linux
Change-Id: Ib925bbedbdda11bb50e47f8dd55c2f5af7c53698
Reviewed-on: https://chromium-review.googlesource.com/1357699
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Because the alignment of the data passed into from_slice is not checked,
it is very easy to pass in unaligned data that will get dereferenced at
a later point in the code. On ARM, this will lead to a SIGBUS.
This change adds an alignment check to prevent getting a signal.
Instead, the caller will get `None`.
BUG=chromium:900962
TEST=cargo test -p data_model
Change-Id: I7a0f835f7d0ffd8c3d44bbcd80a790027f652bc9
Reviewed-on: https://chromium-review.googlesource.com/1343989
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Hopefully the changes are self-explanatory and uncontroversial. This
eliminates much of the noise from `cargo clippy` and, for my purposes,
gives me a reasonable way to use it as a tool when writing and reviewing
code.
Here is the Clippy invocation I was using:
cargo +nightly clippy -- -W clippy::correctness -A renamed_and_removed_lints -Aclippy::{blacklisted_name,borrowed_box,cast_lossless,cast_ptr_alignment,enum_variant_names,identity_op,if_same_then_else,mut_from_ref,needless_pass_by_value,new_without_default,new_without_default_derive,or_fun_call,ptr_arg,should_implement_trait,single_match,too_many_arguments,trivially_copy_pass_by_ref,unreadable_literal,unsafe_vector_initialization,useless_transmute}
TEST=cargo check --features wl-dmabuf,gpu,usb-emulation
TEST=boot linux
Change-Id: I55eb1b4a72beb2f762480e3333a921909314a0a2
Reviewed-on: https://chromium-review.googlesource.com/1356911
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
These duplicate the doc comments found in `trait PciDevice`. I am
removing them because a sensible reader would already assume that they
have fallen out of sync with the doc comments in the trait, and thus
refer to the trait definition anyway.
TEST=none
Change-Id: Id86936a6f2a1b6c78a000b107bb4fc8ed78e40f9
Reviewed-on: https://chromium-review.googlesource.com/1355350
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Usb emulation depend on libusb. This path install libusb-1.0 to the
container.
BUG=chromium:831850
TEST=local build docker and run kokoro_simulator.sh
Change-Id: I2fa406914bf7cfe9a790ec945e15eb387e964d8e
Reviewed-on: https://chromium-review.googlesource.com/1356766
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This adds the ability to regenerate the reference counts by walking all
of the L1/L2 tables and headers to find all reachable clusters. This is
necessary for the next patch, which will use the reference count tables
to find unused clusters to reuse.
BUG=chromium:899273
TEST=cargo test -p cqow
Change-Id: I93dd00d381d8d33010fddfc10aa18ca32586e1f4
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1327821
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This wrapper will be part of usb emulation backend.
BUG=chromium:831850
TEST=local build
Change-Id: I084b15201941e4c16c4e3ff9b967e55db09db567
Reviewed-on: https://chromium-review.googlesource.com/1124870
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Jingkui Wang <jkwang@google.com>
Now that libc includes the fallocate64 function declaration that we
need, we can drop our own declaration and resolve the TODOs.
BUG=None
TEST=cargo build
Change-Id: I7548a561d672739fa7cdd7eb996ad2b2e307d69a
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1352866
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Our virtio devices are all "modern" (no legacy/transitional support).
Add VIRTIO_F_VERSION_1 to the features() handler for all virtio devices
that didn't already have it.
This lets us remove the hack that forced VIRTIO_F_VERSION_1 on for all
devices.
BUG=None
TEST=build_test; boot crosvm on kevin
Change-Id: I008926a9075679aae46069aa37a14504f10e8584
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1313013
Reviewed-by: Zach Reizner <zachr@chromium.org>
Instead of using unaligned memory. Allocate aligned memory and copy into it, we
were already doing an clone. There should be no overhead for this new
approach.
BUG=chromium:900962
TEST=build and run
Change-Id: I011d4c93a872d7d285e8898ff332f3ee1ef104a9
Reviewed-on: https://chromium-review.googlesource.com/1344225
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When wl-dmabuf is not enabled, rustc complains about unused imports and
enum values. Add compiler directives to silence the warnings.
BUG=None
TEST='cargo build', 'emerge-nami crosvm'
Change-Id: Ib39735d329f8aa835c0b5842b10bfe78d0e578d9
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1327827
Rustfmt currently does not touch the content of macro invocations. Also
it used to have a bug where if it changed indentation of a block of code
containing a multi-line macro invocation then the macro input would not
get correspondingly indented. That bug was visible across some of the
code here.
For example:
// rustfmt decides to un-indent the surrounding block:
let data_size_in_bytes = quote!(
( #( #field_types::FIELD_WIDTH as usize )+* ) / 8
);
// poorly formatted resulting code:
let data_size_in_bytes = quote!(
( #( #field_types::FIELD_WIDTH as usize )+* ) / 8
);
// should have been:
let data_size_in_bytes = quote!(
( #( #field_types::FIELD_WIDTH as usize )+* ) / 8
);
TEST=cargo check crosvm
TEST=cargo test each of the three proc-macro crates
CQ-DEPEND=CL:1338507
Change-Id: Id2d456a8d85d719fbc0a65624f153f0f9df6f500
Reviewed-on: https://chromium-review.googlesource.com/1338508
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
The virtio specification only defines feature bits in the 0-63 range
currently, so we can represent the features as a u64. The Linux kernel
makes the same simplifying assumption, and very few features have been
defined beyond the first 32 bits, so this is probably safe for a while.
This allows the device models to be simplified, since they no longer
need to deal with the features paging mechanism (it is handled by the
generic virtio transport code).
BUG=None
TEST=build_test; boot termina on kevin
Change-Id: I6fd86907b2bdf494466c205e85072ebfeb7f5b73
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1313012
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Remove the double underscore in front of `__has_extension` in crosvm.h.
Double underscores in identifiers are reserved for the compiler's
internal use and as it so happens, `__has_extension` is a macro that
clang defines for code to determine whether the compiler supports a
given feature.
We shouldn't be using double underscores in any of the variable names in
this header file but for now just fix the problematic one so that the
code can actually compile under clang.
BUG=b:80150167
TEST=Compile one of the test plugins with clang
Change-Id: Ibb59e72c968a7f245bd6cc693da99f9263eedf33
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1341100
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The rust-toolchain file defines a local toolchain override that is
respected by rustup when running Cargo commands. This override applies
to the directory containing the rust-toolchain file as well as its
subdirectories. It makes it so that running `cargo check` or `cargo fmt`
always uses the intended toolchain, unless overridden by e.g. `cargo
+nightly check`, regardless of what toolchain the user has selected as
global default. No more accidentally running a too new or old version of
rustfmt!
We will need to bump this version number when rolling to a newer
toolchain in ebuild. When that happens, local Cargo commands by other
crosvm developers will automatically download the new toolchain.
For details on rust-toolchain:
https://github.com/rust-lang-nursery/rustup.rs#the-toolchain-filehttps://github.com/rust-lang-nursery/rustup.rs#override-precedence
This file is ignored during emerge. Verified by setting rust-toolchain
to a bogus version number and emerge succeeded anyway.
TEST=rustc --version
TEST=rustc +nightly --version
TEST=cargo check
TEST=cargo fmt --all
TEST=cargo +nightly check
TEST=build_packages
Change-Id: Ia4d74a0c8c632bcd7b171f6c039b068fb30b5502
Reviewed-on: https://chromium-review.googlesource.com/1340728
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Refactor existing code to use msg_socket.
BUG=None
TEST=local build and run
Change-Id: Iee72326b330e035303f679e1aedd6e5d18ad4f8a
Reviewed-on: https://chromium-review.googlesource.com/1260260
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This matches the x86 mptable change from commit ac242df107.
BUG=None
TEST=Boot termina on kevin
Change-Id: I370419f3edc1271df4ae7cdbe4b35241945c2757
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1333942
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The refcount table needs to include not only the data clusters and
reftable clusters but also the L1 and L2 tables and main qcow2 header.
Also add sanity checking to prevent allocating a cluster that cannot be
indexed with the current reference count table size.
BUG=chromium:899273
TEST=cargo test -p qcow
Change-Id: I9da4515db3dccbabdeee4f60dc392b5b42d62cb2
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1308833
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The `convert_to_*` functions take ownership of the passed FDs even
though they should not according to the function's contract. This change
clones the passed FDs so that the caller can retain ownership of its
FDs.
This change also wraps most of the implementations in catch_unwind so
that panics do not unwind past FFI boundaries, which is undefined
behavior.
BUG=chromium:905799
TEST=in crosh: `vmc export <vm name> <file name>`
Change-Id: I2f65ebff51243675d0854574d8fd02cec1b237a4
Reviewed-on: https://chromium-review.googlesource.com/1338501
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The qcow_utils crate is not a dependency of crosvm and should not be
built in the same phase as crosvm. Doing so was harmless before the
recent rustc/cargo changes, which seem to be triggering some kind of
race condition. This change works around the bug.
CQ-DEPEND=CL:1336738
TEST=cargo test --release
BUG=chromium:900366
Change-Id: I01048128b20cf06580e809f6701688ab72e7756d
Reviewed-on: https://chromium-review.googlesource.com/1336737
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Turns out my cargo-fmt binary was being sourced from ~/.cargo/bin, which
was very out of date. Hopefully less formatting issues come out of my
chroot now.
TEST=cargo fmt --all -- --check
BUG=None
Change-Id: I50592e2781835840dc5d589c681b3438d6de3370
Reviewed-on: https://chromium-review.googlesource.com/1324669
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This change includes relevant toolchain versions and some echos
announcing the stages of testing. This should make kokoro's logs a bit
easier to diagnose.
TEST=kokoro_simulator.sh
BUG=None
Change-Id: I6d51d8ae6618a244338605d61882eeedcb1f5b79
Reviewed-on: https://chromium-review.googlesource.com/1324689
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
The types from msg_socket were assumed to be in scope for the custom
derive implementation, which would cause mysterious compiler errors if
the custom derive was invoked in a module without msg_socket types in
scope.
This CL uses fully qualified types in the generated output to avoid
these errors.
This change also uses `extern crate msg_socket` in case the call site
doesn't have it in scope.
BUG=None
TEST=cargo test -p msg_on_socket_derive
Change-Id: Ie6443cd4ffc070d27e71de123090a58f19846472
Reviewed-on: https://chromium-review.googlesource.com/1314208
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Jingkui Wang <jkwang@google.com>
