In Rust 2018 edition, `extern crate` is no longer required for importing
from other crates. Instead of writing:
extern crate dep;
use dep::Thing;
we write:
use dep::Thing;
In this approach, macros are imported individually from the declaring
crate rather than through #[macro_use]. Before:
#[macro_use]
extern crate sys_util;
After:
use sys_util::{debug, error};
The only place that `extern crate` continues to be required is in
importing the compiler's proc_macro API into a procedural macro crate.
This will hopefully be fixed in a future Rust release.
extern crate proc_macro;
TEST=cargo check
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
TEST=local kokoro
Change-Id: I0b43768c0d81f2a250b1959fb97ba35cbac56293
Reviewed-on: https://chromium-review.googlesource.com/1565302
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Macros were previously imported through `#[macro_use] extern crate`,
which is basically a glob import of all macros from the crate. As of
2018 edition of Rust, `extern crate` is no longer required and macros
are imported individually like any other item from a dependency. This CL
fills in all the appropriate macro imports that will allow us to remove
our use of `extern crate` in a subsequent CL.
TEST=cargo check --all-features --tests
TEST=kokoro
Change-Id: If2ec08b06b743abf5f62677c6a9927c3d5d90a54
Reviewed-on: https://chromium-review.googlesource.com/1565546
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
The enumn and bitfield macros generate global constants based on names
that are typically in CamelCase, but the new on-by-default warning
non_upper_case_globals complains about them.
Fixes warnings of the form:
warning: associated constant `...` should have an upper case name
when using enumn or bitfield.
BUG=None
TEST=`cargo build` without warnings
Change-Id: Id908df1dcdf58288c2cbdff574cb70be2026bde6
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1536558
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
user-defined tuple struct could be used to improve type safety.
TEST=cargo test
BUG=None
Change-Id: I8ce10fc51b79c277ab23029513b707f3dd621af5
Reviewed-on: https://chromium-review.googlesource.com/1546432
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
If we know the width of an enum type, we don't need 'power of 2' number
of variants.
BUG=None
TEST=cargo test
Change-Id: I8148b28f86bb8e4fd4f67d8a6382fc713dad1439
Reviewed-on: https://chromium-review.googlesource.com/1530455
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
tests
Setter/Getter types will allow better enum fields.
Generated tests should be tests for bit_field cargo rather than the
defined bit_field struct.
BUG=None
TEST=cargo test
Change-Id: Ib3594e35e28fc393d49c476c9c83fc632cac3190
Reviewed-on: https://chromium-review.googlesource.com/1530454
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Previously, the getter and setter functions generated for a bitfield
struct by #[bitfield] all operated on primitive types like bool, u8, u16
etc.
This CL adds support for getters and setters defined in terms of
user-defined enums.
We make an enum bitfield-compatible by adding #[bitfield]. The number of
variants must be a power of 2.
#[bitfield]
enum TwoBits {
Zero = 0b00,
One = 0b01,
Two = 0b10,
Three = 0b11,
}
And then it may be used to specify a field in a bitfield struct.
#[bitfield]
struct Struct {
prefix: BitField1,
two_bits: TwoBits,
suffix: BitField5,
}
The generated getters and setters for this struct would have the
following signatures:
impl Struct {
fn get_prefix(&self) -> u8;
fn set_prefix(&mut self, val: u8);
fn get_two_bits(&self) -> TwoBits;
fn set_two_bits(&mut self, val: TwoBits);
fn get_suffix(&self) -> u8;
fn set_suffix(&mut self, val: u8);
}
TEST=`cargo test` the bit_field and bit_field_derive crates
TEST=`cargo check` crosvm
Change-Id: Ibc8923e2877fda6ae8da5767731edcb68721a434
Reviewed-on: https://chromium-review.googlesource.com/1519686
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Changes in this CL:
- Crate-level documentation for bit_field crate!
- Use absolute paths within generated code so that the caller is no
longer required to have various implementation details from the
bit_field crate in scope.
- Check that the total number of bits is a multiple of 8. Previously, it
would generate compilable code that panicked when invoking accessors.
- Provide B0 .. B64 as shorthand for BitField0 .. BitField64.
- Use `bool` as the bool specifier rather than BitFieldBool.
- Disallow BitFieldSpecifier impls outside the bit_field crate.
- Simplify declaration of the BitFieldN types by replacing the recursive
macro_rules with a simpler procedural macro.
TEST=`cargo test` in bit_field and in bit_field_derive
Change-Id: Ica9347bc89901de85f74366edd038fb5d8042ee6
Reviewed-on: https://chromium-review.googlesource.com/1382578
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Jingkui Wang <jkwang@google.com>
BitFieldSpecifiers are now generated by macros.
Can use BitFieldBool to specify a bool field.
BUG=chromium:831850
TEST=local cargo build/test
Change-Id: Id6b4a773ab612cea39ba811c3ec1da212b618ba2
Reviewed-on: https://chromium-review.googlesource.com/1356912
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
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>
Support macro derive(BitField) to make life easier.
BUG=None.
TEST=local build and run test.
Change-Id: I582620de250017fb7c0b601f9ad4fbcbbc2fe02a
Reviewed-on: https://chromium-review.googlesource.com/1069331
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
