crates/open-enum/src/lib.rs - platform/external/rust/android-crates-io - Git at Google

 // Copyright 2022 Google LLC
 //
 // Licensed under the Apache License, Version 2.0 (the "License");
 // you may not use this file except in compliance with the License.
 // You may obtain a copy of the License at
 //
 //      http://www.apache.org/licenses/LICENSE-2.0
 //
 // Unless required by applicable law or agreed to in writing, software
 // distributed under the License is distributed on an "AS IS" BASIS,
 // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 // See the License for the specific language governing permissions and
 // limitations under the License.

 //! Rust enums are _closed_, meaning that the integer value distinguishing an enum, its _discriminant_,
 //! must be one of the variants listed. If the integer value isn't one of those discriminants, it
 //! is considered immediate [undefined behavior][ub]. This is true for enums with and without fields.
 //!
 //! This has some disadvantages:
 //! - in constrained environments, closed enums can require premature runtime checks when using
 //!   `TryFrom` to convert from an integer. This is doubly true if the value will be checked again
 //!   at a later point, such as with a C library.
 //! - an outdated binary using an enum won't preserve the value of an unknown field when reserializing
 //!   data without an extra `Unrecognized` value making the type more expensive than an integer.
 //! - it can introduce Undefined Behavior at unexpected times if the author is unfamiliar with
 //!   the [rules of writing `unsafe` Rust][nomicon].
 //!
 //! In constrast, C++ [scoped enumerations][cpp-scoped-enum] are _open_, meaning that the enum is a
 //! strongly-typed integer that could hold any value, though with a scoped set of well-known values.
 //!
 //! The _open enum_ pattern lets you have this in Rust. With a [newtype][newtype] and associated constants,
 //! the [open_enum][open_enum] macro turns this enum declaration:
 //!
 //! ```
 //! # use open_enum::open_enum;
 //! #[open_enum]
 //! enum Color {
 //!     Red,
 //!     Green,
 //!     Blue,
 //!     Orange,
 //!     Black,
 //! }
 //! ```
 //!
 //! into a tuple struct with associated constants:
 //!
 //! ```
 //! #[derive(PartialEq, Eq)]  // In order to work in `match`.
 //! struct Color(pub i8);  // Automatic integer type, can be specified with #[repr]
 //!
 //! impl Color {
 //!     pub const Red: Self = Color(0);
 //!     pub const Green: Self = Color(1);
 //!     pub const Blue: Self = Color(2);
 //!     pub const Orange: Self = Color(3);
 //!     pub const Black: Self = Color(4);
 //! }
 //! ```
 //!
 //! There are clear readability benefits to using field-less `enum`s to represent enumerated integer data.
 //! It provides more type safety than a raw integer, the `enum` syntax is consise, and it provides a
 //! set of constants grouped under a type that can have methods.
 //!
 //! # Usage
 //! Usage is similar to regular `enum`s, but with some key differences.
 //!
 //! ```
 //! # use open_enum::open_enum;
 //! # #[open_enum]
 //! # #[derive(Debug)]
 //! # enum Color {
 //! #     Red,
 //! #     Green,
 //! #     Blue,
 //! #     Orange,
 //! #     Black,
 //! # }
 //! // Construct an open enum with the same `EnumName::VariantName` syntax.
 //! let mut blood_of_angry_men = Color::Red;
 //!
 //! // Access the integer value with `.0`.
 //! // This does not work: `Color::Red as u8`.
 //! assert_eq!(blood_of_angry_men.0, 0);
 //!
 //! // Construct an open enum with an arbitrary integer value like any tuple struct.
 //! let dark_of_ages_past = Color(4);
 //!
 //! // open enums always implement `PartialEq` and `Eq`, unlike regular enums.
 //! assert_eq!(dark_of_ages_past, Color::Black);
 //!
 //! // This is outside of the known colors - but that's OK!
 //! let this_is_fine = Color(10);
 //!
 //! // A match is always non-exhaustive - requiring a wildcard branch.
 //! match this_is_fine {
 //!     Color::Red => panic!("a world about to dawn"),
 //!     Color::Green => panic!("grass"),
 //!     Color::Blue => panic!("蒼: not to be confused with 緑"),
 //!     Color::Orange => panic!("fun fact: the fruit name came first"),
 //!     Color::Black => panic!("the night that ends at last"),
 //!     // Wildcard branch, if we don't recognize the value. `x =>` also works.
 //!     Color(value) => assert_eq!(value, 10),
 //! }
 //!
 //! // Unlike a regular enum, you can pass the discriminant as a reference.
 //! fn increment(x: &mut i8) {
 //!     *x += 1;
 //! }
 //!
 //! increment(&mut blood_of_angry_men.0);
 //! // These aren't men, they're skinks!
 //! assert_eq!(blood_of_angry_men, Color::Green);
 //!
 //! ```
 //!
 //! ## Integer type
 //! `open_enum` will automatically determine an appropriately sized integer[^its-all-isize] to
 //! represent the enum, if possible[^nonliterals-are-hard]. To choose a specific representation, it's the same
 //! as a regular `enum`: add `#[repr(type)]`.
 //! You can also specify `#[repr(C)]` to choose a C `int`.[^repr-c-feature][^repr-c-weird]
 //!
 //! If you specify an explicit `repr`, the output struct will be `#[repr(transparent)]`.
 //!
 //! ```
 //! # use open_enum::open_enum;
 //! #[open_enum]
 //! #[repr(i16)]
 //! #[derive(Debug)]
 //! enum Fruit {
 //!     Apple,
 //!     Banana,
 //!     Kumquat,
 //!     Orange,
 //! }
 //!
 //! assert_eq!(Fruit::Banana.0, 1i16);
 //! assert_eq!(Fruit::Kumquat, Fruit(2));
 //!
 //! ```
 //!  <div class="example-wrap" style="display:inline-block"><pre class="compile_fail" style="white-space:normal;font:inherit;">
 //!
 //!  **Warning**: `open_enum` may change the automatic integer representation for a given enum
 //! in a future version with a minor version bump - it is not considered a breaking change.
 //! Do not depend on this type remaining stable - use an explicit `#[repr]` for stability.
 //!
 //! </pre></div>
 //!
 //! [^its-all-isize]: Like regular `enum`s, the declared discriminant for enums without an explicit `repr`
 //! is interpreted as an `isize` regardless of the automatic storage type chosen.
 //!
 //! [^nonliterals-are-hard]: This optimization fails if the `enum` declares a non-literal constant expression
 //! as one of its discriminant values, and falls back to `isize`. To avoid this, specify an explicit `repr`.
 //!
 //! [^repr-c-weird]: Note that this might not actually be the correct default `enum` size for C on all platforms,
 //!                  since the [compiler could choose something smaller than `int`](https://stackoverflow.com/a/366026).
 //!
 //! [^repr-c-feature]: This requires either the `std` or `libc_` feature (note the underscore)
 //!
 //! ## Aliasing variants
 //! Regular `enum`s cannot have multiple variants with the same discriminant.
 //! However, since `open_enum` produces associated constants, multiple
 //! names can represent the same integer value. By default, `open_enum`
 //! rejects aliasing variants, but it can be allowed with the `allow_alias` option:
 //!
 //! ```
 //! # use open_enum::open_enum;
 //! #[open_enum(allow_alias)]
 //! #[derive(Debug)]
 //! enum Character {
 //!     Viola = 0,
 //!     Cesario = 0,
 //!     Sebastian,
 //!     Orsino,
 //!     Olivia,
 //!     Malvolio,
 //! }
 //!
 //! assert_eq!(Character::Viola, Character::Cesario);
 //!
 //! ```
 //!
 //!
 //!
 //! # Custom debug implementation
 //! `open_enum` will generate a debug implementation that mirrors the standard `#[derive(Debug)]` for normal Rust enums
 //! by printing the name of the variant rather than the value contained, if the value is a named variant.
 //!
 //! However, if an enum has `#[open_enum(allow_alias)]` specified, the debug representation will be the numeric value only.
 //!
 //! For example, this given enum,
 //! ```
 //! # use open_enum::open_enum;
 //! #[open_enum]
 //! #[derive(Debug)]
 //! enum Fruit {
 //!     Apple,
 //!     Pear,
 //!     Banana,
 //!     Blueberry = 5,
 //!     Raspberry,
 //! }
 //! ```
 //!
 //! will have the following debug implementation emitted:
 //! ```
 //! # use open_enum::open_enum;
 //! # #[open_enum]
 //! # enum Fruit {
 //! #     Apple,
 //! #     Pear,
 //! #     Banana,
 //! #     Blueberry = 5,
 //! #     Raspberry,
 //! # }
 //! # impl ::core::fmt::Debug for Fruit {
 //! fn fmt(&self, fmt: &mut ::core::fmt::Formatter) -> ::core::fmt::Result {
 //!         #![allow(unreachable_patterns)]
 //!         let s = match *self {
 //!             Self::Apple => stringify!(Apple),
 //!             Self::Pear => stringify!(Pear),
 //!             Self::Banana => stringify!(Banana),
 //!             Self::Blueberry => stringify!(Blueberry),
 //!             Self::Raspberry => stringify!(Raspberry),
 //!             _ => {
 //!                 return fmt.debug_tuple(stringify!(Fruit)).field(&self.0).finish();
 //!             }
 //!         };
 //!         fmt.pad(s)
 //!     }
 //! # }
 //! ```
 //!
 //! # Compared with `#[non_exhuastive]`
 //! The [`non_exhaustive`][non-exhaustive] attribute indicates that a type or variant
 //! may have more fields or variants added in the future. When applied to an `enum` (not its variants),
 //! it requires that foreign crates provide a wildcard arm when `match`ing.
 //! Since open enums are inherently non-exhaustive[^mostly-non-exhaustive], this attribute is incompatible
 //! with `open_enum`. Unlike `non_exhaustive`, open enums also require a wildcard branch on `match`es in
 //! the defining crate.
 //!
 //! [^mostly-non-exhaustive]: Unless the enum defines a variant for every value of its underlying integer.
 //!
 //! # Disadvantages of open enums
 //! - The kind listed in the source code, an `enum`, is not the same as the actual output, a `struct`,
 //!   which could be confusing or hard to debug, since its usage is similar, but not exactly the same.
 //! - No niche optimization: `Option<Color>` is 1 byte as a regular enum,
 //!   but 2 bytes as an open enum.
 //! - No pattern-matching assistance in rust-analyzer.
 //! - You must have a wildcard case when pattern matching.
 //! - `match`es that exist elsewhere won't break when you add a new variant,
 //!   similar to `#[non_exhaustive]`. However, it also means you may accidentally
 //!   forget to fill out a branch arm.
 //!
 //!
 //! [cpp-scoped-enum]: https://en.cppreference.com/w/cpp/language/enum#Scoped_enumerations
 //! [nomicon]: https://doc.rust-lang.org/nomicon/
 //! [non-exhaustive]: https://doc.rust-lang.org/reference/attributes/type_system.html#the-non_exhaustive-attribute
 //! [ub]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html

 #![no_std]

 /// Constructs an *open* enum from a Rust enum definition,
 /// allowing it to represent more than just its listed variants.
 ///
 /// See the [crate documentation](crate) for more details.
 ///
 /// # Example
 /// ```
 /// # use open_enum::open_enum;
 /// #[open_enum]
 /// #[derive(Debug)]
 /// enum Color {
 ///     Red,
 ///     Green,
 ///     Blue,
 ///     Orange,
 ///     Black,
 /// }
 ///
 /// assert_eq!(Color::Red, Color(0));
 /// assert_eq!(Color(10).0, 10);
 /// ```
 ///
 /// # Options
 /// - `allow_alias[ = $bool]`: default `false`. Allows duplicate discriminant values for variants.
 /// - `inner_vis = $vis`: default `pub`. Specifies the visibility of the inner integer.
 ///
 /// # Integer type
 /// `open_enum` configures the discriminant type by intercepting a `repr` attribute on the enum.
 /// If done, the open enum is `#[repr(transparent)]` over the provided integer type.
 /// Otherwise, variant discriminants are interpreted as `isize` and an automatic integer type chosen.
 ///
 /// # `PartialEq`/`Eq`
 /// Open enums implement `PartialEq` and `Eq` in order to work in a `match` statement.
 pub use open_enum_derive::open_enum;

 /// Utility items only to be used by macros. Do not expect API stability.
 #[doc(hidden)]
 pub mod __private {
     #[cfg(all(feature = "libc", not(feature = "std")))]
     pub use libc::c_int;

     #[cfg(feature = "std")]
     extern crate std;

     #[cfg(feature = "std")]
     pub use std::os::raw::c_int;
 }
	// Copyright 2022 Google LLC
	//
	// Licensed under the Apache License, Version 2.0 (the "License");
	// you may not use this file except in compliance with the License.
	// You may obtain a copy of the License at
	//
	// http://www.apache.org/licenses/LICENSE-2.0
	//
	// Unless required by applicable law or agreed to in writing, software
	// distributed under the License is distributed on an "AS IS" BASIS,
	// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	// See the License for the specific language governing permissions and
	// limitations under the License.

	//! Rust enums are _closed_, meaning that the integer value distinguishing an enum, its _discriminant_,
	//! must be one of the variants listed. If the integer value isn't one of those discriminants, it
	//! is considered immediate [undefined behavior][ub]. This is true for enums with and without fields.
	//!
	//! This has some disadvantages:
	//! - in constrained environments, closed enums can require premature runtime checks when using
	//! `TryFrom` to convert from an integer. This is doubly true if the value will be checked again
	//! at a later point, such as with a C library.
	//! - an outdated binary using an enum won't preserve the value of an unknown field when reserializing
	//! data without an extra `Unrecognized` value making the type more expensive than an integer.
	//! - it can introduce Undefined Behavior at unexpected times if the author is unfamiliar with
	//! the [rules of writing `unsafe` Rust][nomicon].
	//!
	//! In constrast, C++ [scoped enumerations][cpp-scoped-enum] are _open_, meaning that the enum is a
	//! strongly-typed integer that could hold any value, though with a scoped set of well-known values.
	//!
	//! The _open enum_ pattern lets you have this in Rust. With a [newtype][newtype] and associated constants,
	//! the [open_enum][open_enum] macro turns this enum declaration:
	//!
	//! ```
	//! # use open_enum::open_enum;
	//! #[open_enum]
	//! enum Color {
	//! Red,
	//! Green,
	//! Blue,
	//! Orange,
	//! Black,
	//! }
	//! ```
	//!
	//! into a tuple struct with associated constants:
	//!
	//! ```
	//! #[derive(PartialEq, Eq)] // In order to work in `match`.
	//! struct Color(pub i8); // Automatic integer type, can be specified with #[repr]
	//!
	//! impl Color {
	//! pub const Red: Self = Color(0);
	//! pub const Green: Self = Color(1);
	//! pub const Blue: Self = Color(2);
	//! pub const Orange: Self = Color(3);
	//! pub const Black: Self = Color(4);
	//! }
	//! ```
	//!
	//! There are clear readability benefits to using field-less `enum`s to represent enumerated integer data.
	//! It provides more type safety than a raw integer, the `enum` syntax is consise, and it provides a
	//! set of constants grouped under a type that can have methods.
	//!
	//! # Usage
	//! Usage is similar to regular `enum`s, but with some key differences.
	//!
	//! ```
	//! # use open_enum::open_enum;
	//! # #[open_enum]
	//! # #[derive(Debug)]
	//! # enum Color {
	//! # Red,
	//! # Green,
	//! # Blue,
	//! # Orange,
	//! # Black,
	//! # }
	//! // Construct an open enum with the same `EnumName::VariantName` syntax.
	//! let mut blood_of_angry_men = Color::Red;
	//!
	//! // Access the integer value with `.0`.
	//! // This does not work: `Color::Red as u8`.
	//! assert_eq!(blood_of_angry_men.0, 0);
	//!
	//! // Construct an open enum with an arbitrary integer value like any tuple struct.
	//! let dark_of_ages_past = Color(4);
	//!
	//! // open enums always implement `PartialEq` and `Eq`, unlike regular enums.
	//! assert_eq!(dark_of_ages_past, Color::Black);
	//!
	//! // This is outside of the known colors - but that's OK!
	//! let this_is_fine = Color(10);
	//!
	//! // A match is always non-exhaustive - requiring a wildcard branch.
	//! match this_is_fine {
	//! Color::Red => panic!("a world about to dawn"),
	//! Color::Green => panic!("grass"),
	//! Color::Blue => panic!("蒼: not to be confused with 緑"),
	//! Color::Orange => panic!("fun fact: the fruit name came first"),
	//! Color::Black => panic!("the night that ends at last"),
	//! // Wildcard branch, if we don't recognize the value. `x =>` also works.
	//! Color(value) => assert_eq!(value, 10),
	//! }
	//!
	//! // Unlike a regular enum, you can pass the discriminant as a reference.
	//! fn increment(x: &mut i8) {
	//! *x += 1;
	//! }
	//!
	//! increment(&mut blood_of_angry_men.0);
	//! // These aren't men, they're skinks!
	//! assert_eq!(blood_of_angry_men, Color::Green);
	//!
	//! ```
	//!
	//! ## Integer type
	//! `open_enum` will automatically determine an appropriately sized integer[^its-all-isize] to
	//! represent the enum, if possible[^nonliterals-are-hard]. To choose a specific representation, it's the same
	//! as a regular `enum`: add `#[repr(type)]`.
	//! You can also specify `#[repr(C)]` to choose a C `int`.[^repr-c-feature][^repr-c-weird]
	//!
	//! If you specify an explicit `repr`, the output struct will be `#[repr(transparent)]`.
	//!
	//! ```
	//! # use open_enum::open_enum;
	//! #[open_enum]
	//! #[repr(i16)]
	//! #[derive(Debug)]
	//! enum Fruit {
	//! Apple,
	//! Banana,
	//! Kumquat,
	//! Orange,
	//! }
	//!
	//! assert_eq!(Fruit::Banana.0, 1i16);
	//! assert_eq!(Fruit::Kumquat, Fruit(2));
	//!
	//! ```
	//! <div class="example-wrap" style="display:inline-block"><pre class="compile_fail" style="white-space:normal;font:inherit;">
	//!
	//! Warning: `open_enum` may change the automatic integer representation for a given enum
	//! in a future version with a minor version bump - it is not considered a breaking change.
	//! Do not depend on this type remaining stable - use an explicit `#[repr]` for stability.
	//!
	//! </pre></div>
	//!
	//! [^its-all-isize]: Like regular `enum`s, the declared discriminant for enums without an explicit `repr`
	//! is interpreted as an `isize` regardless of the automatic storage type chosen.
	//!
	//! [^nonliterals-are-hard]: This optimization fails if the `enum` declares a non-literal constant expression
	//! as one of its discriminant values, and falls back to `isize`. To avoid this, specify an explicit `repr`.
	//!
	//! [^repr-c-weird]: Note that this might not actually be the correct default `enum` size for C on all platforms,
	//! since the [compiler could choose something smaller than `int`](https://stackoverflow.com/a/366026).
	//!
	//! [^repr-c-feature]: This requires either the `std` or `libc_` feature (note the underscore)
	//!
	//! ## Aliasing variants
	//! Regular `enum`s cannot have multiple variants with the same discriminant.
	//! However, since `open_enum` produces associated constants, multiple
	//! names can represent the same integer value. By default, `open_enum`
	//! rejects aliasing variants, but it can be allowed with the `allow_alias` option:
	//!
	//! ```
	//! # use open_enum::open_enum;
	//! #[open_enum(allow_alias)]
	//! #[derive(Debug)]
	//! enum Character {
	//! Viola = 0,
	//! Cesario = 0,
	//! Sebastian,
	//! Orsino,
	//! Olivia,
	//! Malvolio,
	//! }
	//!
	//! assert_eq!(Character::Viola, Character::Cesario);
	//!
	//! ```
	//!
	//!
	//!
	//! # Custom debug implementation
	//! `open_enum` will generate a debug implementation that mirrors the standard `#[derive(Debug)]` for normal Rust enums
	//! by printing the name of the variant rather than the value contained, if the value is a named variant.
	//!
	//! However, if an enum has `#[open_enum(allow_alias)]` specified, the debug representation will be the numeric value only.
	//!
	//! For example, this given enum,
	//! ```
	//! # use open_enum::open_enum;
	//! #[open_enum]
	//! #[derive(Debug)]
	//! enum Fruit {
	//! Apple,
	//! Pear,
	//! Banana,
	//! Blueberry = 5,
	//! Raspberry,
	//! }
	//! ```
	//!
	//! will have the following debug implementation emitted:
	//! ```
	//! # use open_enum::open_enum;
	//! # #[open_enum]
	//! # enum Fruit {
	//! # Apple,
	//! # Pear,
	//! # Banana,
	//! # Blueberry = 5,
	//! # Raspberry,
	//! # }
	//! # impl ::core::fmt::Debug for Fruit {
	//! fn fmt(&self, fmt: &mut ::core::fmt::Formatter) -> ::core::fmt::Result {
	//! #![allow(unreachable_patterns)]
	//! let s = match *self {
	//! Self::Apple => stringify!(Apple),
	//! Self::Pear => stringify!(Pear),
	//! Self::Banana => stringify!(Banana),
	//! Self::Blueberry => stringify!(Blueberry),
	//! Self::Raspberry => stringify!(Raspberry),
	//! _ => {
	//! return fmt.debug_tuple(stringify!(Fruit)).field(&self.0).finish();
	//! }
	//! };
	//! fmt.pad(s)
	//! }
	//! # }
	//! ```
	//!
	//! # Compared with `#[non_exhuastive]`
	//! The [`non_exhaustive`][non-exhaustive] attribute indicates that a type or variant
	//! may have more fields or variants added in the future. When applied to an `enum` (not its variants),
	//! it requires that foreign crates provide a wildcard arm when `match`ing.
	//! Since open enums are inherently non-exhaustive[^mostly-non-exhaustive], this attribute is incompatible
	//! with `open_enum`. Unlike `non_exhaustive`, open enums also require a wildcard branch on `match`es in
	//! the defining crate.
	//!
	//! [^mostly-non-exhaustive]: Unless the enum defines a variant for every value of its underlying integer.
	//!
	//! # Disadvantages of open enums
	//! - The kind listed in the source code, an `enum`, is not the same as the actual output, a `struct`,
	//! which could be confusing or hard to debug, since its usage is similar, but not exactly the same.
	//! - No niche optimization: `Option<Color>` is 1 byte as a regular enum,
	//! but 2 bytes as an open enum.
	//! - No pattern-matching assistance in rust-analyzer.
	//! - You must have a wildcard case when pattern matching.
	//! - `match`es that exist elsewhere won't break when you add a new variant,
	//! similar to `#[non_exhaustive]`. However, it also means you may accidentally
	//! forget to fill out a branch arm.
	//!
	//!
	//! [cpp-scoped-enum]: https://en.cppreference.com/w/cpp/language/enum#Scoped_enumerations
	//! [nomicon]: https://doc.rust-lang.org/nomicon/
	//! [non-exhaustive]: https://doc.rust-lang.org/reference/attributes/type_system.html#the-non_exhaustive-attribute
	//! [ub]: https://doc.rust-lang.org/reference/behavior-considered-undefined.html

	#![no_std]

	/// Constructs an open enum from a Rust enum definition,
	/// allowing it to represent more than just its listed variants.
	///
	/// See the [crate documentation](crate) for more details.
	///
	/// # Example
	/// ```
	/// # use open_enum::open_enum;
	/// #[open_enum]
	/// #[derive(Debug)]
	/// enum Color {
	/// Red,
	/// Green,
	/// Blue,
	/// Orange,
	/// Black,
	/// }
	///
	/// assert_eq!(Color::Red, Color(0));
	/// assert_eq!(Color(10).0, 10);
	/// ```
	///
	/// # Options
	/// - `allow_alias[ = $bool]`: default `false`. Allows duplicate discriminant values for variants.
	/// - `inner_vis = $vis`: default `pub`. Specifies the visibility of the inner integer.
	///
	/// # Integer type
	/// `open_enum` configures the discriminant type by intercepting a `repr` attribute on the enum.
	/// If done, the open enum is `#[repr(transparent)]` over the provided integer type.
	/// Otherwise, variant discriminants are interpreted as `isize` and an automatic integer type chosen.
	///
	/// # `PartialEq`/`Eq`
	/// Open enums implement `PartialEq` and `Eq` in order to work in a `match` statement.
	pub use open_enum_derive::open_enum;

	/// Utility items only to be used by macros. Do not expect API stability.
	#[doc(hidden)]
	pub mod __private {
	#[cfg(all(feature = "libc", not(feature = "std")))]
	pub use libc::c_int;

	#[cfg(feature = "std")]
	extern crate std;

	#[cfg(feature = "std")]
	pub use std::os::raw::c_int;
	}