| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Separated out of CL:1513058 to make it possible to land parts
individually while the affected crate has no other significant CLs
pending. This avoids repeatedly introducing non-textual conflicts with
new code that adds `use` statements.
TEST=cargo check
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
Change-Id: Ia446b796d9f6bf3ddf9813ee0678242697dd1f73
Reviewed-on: https://chromium-review.googlesource.com/1519694
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an easy step toward adopting 2018 edition eventually, and will
make any future CL that sets `edition = "2018"` this much smaller.
The module system changes in Rust 2018 are described here:
https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html
Generated by running:
cargo fix --edition --all
in each workspace, followed by bin/fmt.
TEST=cargo check
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
Change-Id: I000ab5e69d69aa222c272fae899464bbaf65f6d8
Reviewed-on: https://chromium-review.googlesource.com/1513054
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>
|
|
|
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>
|