rust/src/libcollections/enum_set.rs

283 lines
7.6 KiB
Rust
Raw Normal View History

// Copyright 2012 The Rust Project Developers. See the COPYRIGHT
// file at the top-level directory of this distribution and at
// http://rust-lang.org/COPYRIGHT.
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.
2014-08-04 05:48:39 -05:00
//! A structure for holding a set of enum variants.
//!
//! This module defines a container which uses an efficient bit mask
//! representation to hold C-like enum variants.
#![unstable(feature = "enumset",
reason = "matches collection reform specification, \
waiting for dust to settle")]
std: Recreate a `collections` module As with the previous commit with `librand`, this commit shuffles around some `collections` code. The new state of the world is similar to that of librand: * The libcollections crate now only depends on libcore and liballoc. * The standard library has a new module, `std::collections`. All functionality of libcollections is reexported through this module. I would like to stress that this change is purely cosmetic. There are very few alterations to these primitives. There are a number of notable points about the new organization: * std::{str, slice, string, vec} all moved to libcollections. There is no reason that these primitives shouldn't be necessarily usable in a freestanding context that has allocation. These are all reexported in their usual places in the standard library. * The `hashmap`, and transitively the `lru_cache`, modules no longer reside in `libcollections`, but rather in libstd. The reason for this is because the `HashMap::new` contructor requires access to the OSRng for initially seeding the hash map. Beyond this requirement, there is no reason that the hashmap could not move to libcollections. I do, however, have a plan to move the hash map to the collections module. The `HashMap::new` function could be altered to require that the `H` hasher parameter ascribe to the `Default` trait, allowing the entire `hashmap` module to live in libcollections. The key idea would be that the default hasher would be different in libstd. Something along the lines of: // src/libstd/collections/mod.rs pub type HashMap<K, V, H = RandomizedSipHasher> = core_collections::HashMap<K, V, H>; This is not possible today because you cannot invoke static methods through type aliases. If we modified the compiler, however, to allow invocation of static methods through type aliases, then this type definition would essentially be switching the default hasher from `SipHasher` in libcollections to a libstd-defined `RandomizedSipHasher` type. This type's `Default` implementation would randomly seed the `SipHasher` instance, and otherwise perform the same as `SipHasher`. This future state doesn't seem incredibly far off, but until that time comes, the hashmap module will live in libstd to not compromise on functionality. * In preparation for the hashmap moving to libcollections, the `hash` module has moved from libstd to libcollections. A previously snapshotted commit enables a distinct `Writer` trait to live in the `hash` module which `Hash` implementations are now parameterized over. Due to using a custom trait, the `SipHasher` implementation has lost its specialized methods for writing integers. These can be re-added backwards-compatibly in the future via default methods if necessary, but the FNV hashing should satisfy much of the need for speedier hashing. A list of breaking changes: * HashMap::{get, get_mut} no longer fails with the key formatted into the error message with `{:?}`, instead, a generic message is printed. With backtraces, it should still be not-too-hard to track down errors. * The HashMap, HashSet, and LruCache types are now available through std::collections instead of the collections crate. * Manual implementations of hash should be parameterized over `hash::Writer` instead of just `Writer`. [breaking-change]
2014-05-29 20:50:12 -05:00
use core::prelude::*;
2015-02-12 09:38:21 -06:00
use core::marker;
2014-09-13 19:37:03 -05:00
use core::fmt;
use core::iter::{FromIterator};
use core::ops::{Sub, BitOr, BitAnd, BitXor};
std: Recreate a `collections` module As with the previous commit with `librand`, this commit shuffles around some `collections` code. The new state of the world is similar to that of librand: * The libcollections crate now only depends on libcore and liballoc. * The standard library has a new module, `std::collections`. All functionality of libcollections is reexported through this module. I would like to stress that this change is purely cosmetic. There are very few alterations to these primitives. There are a number of notable points about the new organization: * std::{str, slice, string, vec} all moved to libcollections. There is no reason that these primitives shouldn't be necessarily usable in a freestanding context that has allocation. These are all reexported in their usual places in the standard library. * The `hashmap`, and transitively the `lru_cache`, modules no longer reside in `libcollections`, but rather in libstd. The reason for this is because the `HashMap::new` contructor requires access to the OSRng for initially seeding the hash map. Beyond this requirement, there is no reason that the hashmap could not move to libcollections. I do, however, have a plan to move the hash map to the collections module. The `HashMap::new` function could be altered to require that the `H` hasher parameter ascribe to the `Default` trait, allowing the entire `hashmap` module to live in libcollections. The key idea would be that the default hasher would be different in libstd. Something along the lines of: // src/libstd/collections/mod.rs pub type HashMap<K, V, H = RandomizedSipHasher> = core_collections::HashMap<K, V, H>; This is not possible today because you cannot invoke static methods through type aliases. If we modified the compiler, however, to allow invocation of static methods through type aliases, then this type definition would essentially be switching the default hasher from `SipHasher` in libcollections to a libstd-defined `RandomizedSipHasher` type. This type's `Default` implementation would randomly seed the `SipHasher` instance, and otherwise perform the same as `SipHasher`. This future state doesn't seem incredibly far off, but until that time comes, the hashmap module will live in libstd to not compromise on functionality. * In preparation for the hashmap moving to libcollections, the `hash` module has moved from libstd to libcollections. A previously snapshotted commit enables a distinct `Writer` trait to live in the `hash` module which `Hash` implementations are now parameterized over. Due to using a custom trait, the `SipHasher` implementation has lost its specialized methods for writing integers. These can be re-added backwards-compatibly in the future via default methods if necessary, but the FNV hashing should satisfy much of the need for speedier hashing. A list of breaking changes: * HashMap::{get, get_mut} no longer fails with the key formatted into the error message with `{:?}`, instead, a generic message is printed. With backtraces, it should still be not-too-hard to track down errors. * The HashMap, HashSet, and LruCache types are now available through std::collections instead of the collections crate. * Manual implementations of hash should be parameterized over `hash::Writer` instead of just `Writer`. [breaking-change]
2014-05-29 20:50:12 -05:00
// FIXME(contentions): implement union family of methods? (general design may be
// wrong here)
/// A specialized set implementation to use enum types.
///
/// It is a logic error for an item to be modified in such a way that the
/// transformation of the item to or from a `usize`, as determined by the
/// `CLike` trait, changes while the item is in the set. This is normally only
/// possible through `Cell`, `RefCell`, global state, I/O, or unsafe code.
#[derive(PartialEq, Eq, PartialOrd, Ord, Hash)]
pub struct EnumSet<E> {
// We must maintain the invariant that no bits are set
// for which no variant exists
2015-02-12 09:38:21 -06:00
bits: usize,
marker: marker::PhantomData<E>,
}
impl<E> Copy for EnumSet<E> {}
impl<E> Clone for EnumSet<E> {
fn clone(&self) -> EnumSet<E> { *self }
}
std: Stabilize the std::fmt module This commit performs a final stabilization pass over the std::fmt module, marking all necessary APIs as stable. One of the more interesting aspects of this module is that it exposes a good deal of its runtime representation to the outside world in order for `format_args!` to be able to construct the format strings. Instead of hacking the compiler to assume that these items are stable, this commit instead lays out a story for the stabilization and evolution of these APIs. There are three primary details used by the `format_args!` macro: 1. `Arguments` - an opaque package of a "compiled format string". This structure is passed around and the `write` function is the source of truth for transforming a compiled format string into a string at runtime. This must be able to be constructed in stable code. 2. `Argument` - an opaque structure representing an argument to a format string. This is *almost* a trait object as it's just a pointer/function pair, but due to the function originating from one of many traits, it's not actually a trait object. Like `Arguments`, this must be constructed from stable code. 3. `fmt::rt` - this module contains the runtime type definitions primarily for the `rt::Argument` structure. Whenever an argument is formatted with nonstandard flags, a corresponding `rt::Argument` is generated describing how the argument is being formatted. This can be used to construct an `Arguments`. The primary interface to `std::fmt` is the `Arguments` structure, and as such this type name is stabilize as-is today. It is expected for libraries to pass around an `Arguments` structure to represent a pending formatted computation. The remaining portions are largely "cruft" which would rather not be stabilized, but due to the stability checks they must be. As a result, almost all pieces have been renamed to represent that they are "version 1" of the formatting representation. The theory is that at a later date if we change the representation of these types we can add new definitions called "version 2" and corresponding constructors for `Arguments`. One of the other remaining large questions about the fmt module were how the pending I/O reform would affect the signatures of methods in the module. Due to [RFC 526][rfc], however, the writers of fmt are now incompatible with the writers of io, so this question has largely been solved. As a result the interfaces are largely stabilized as-is today. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md Specifically, the following changes were made: * The contents of `fmt::rt` were all moved under `fmt::rt::v1` * `fmt::rt` is stable * `fmt::rt::v1` is stable * `Error` is stable * `Writer` is stable * `Writer::write_str` is stable * `Writer::write_fmt` is stable * `Formatter` is stable * `Argument` has been renamed to `ArgumentV1` and is stable * `ArgumentV1::new` is stable * `ArgumentV1::from_uint` is stable * `Arguments::new_v1` is stable (renamed from `new`) * `Arguments::new_v1_formatted` is stable (renamed from `with_placeholders`) * All formatting traits are now stable, as well as the `fmt` method. * `fmt::write` is stable * `fmt::format` is stable * `Formatter::pad_integral` is stable * `Formatter::pad` is stable * `Formatter::write_str` is stable * `Formatter::write_fmt` is stable * Some assorted top level items which were only used by `format_args!` were removed in favor of static functions on `ArgumentV1` as well. * The formatting-flag-accessing methods remain unstable Within the contents of the `fmt::rt::v1` module, the following actions were taken: * Reexports of all enum variants were removed * All prefixes on enum variants were removed * A few miscellaneous enum variants were renamed * Otherwise all structs, fields, and variants were marked stable. In addition to these actions in the `std::fmt` module, many implementations of `Show` and `String` were stabilized as well. In some other modules: * `ToString` is now stable * `ToString::to_string` is now stable * `Vec` no longer implements `fmt::Writer` (this has moved to `String`) This is a breaking change due to all of the changes to the `fmt::rt` module, but this likely will not have much impact on existing programs. Closes #20661 [breaking-change]
2015-01-13 17:42:53 -06:00
#[stable(feature = "rust1", since = "1.0.0")]
std: Rename Show/String to Debug/Display This commit is an implementation of [RFC 565][rfc] which is a stabilization of the `std::fmt` module and the implementations of various formatting traits. Specifically, the following changes were performed: [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0565-show-string-guidelines.md * The `Show` trait is now deprecated, it was renamed to `Debug` * The `String` trait is now deprecated, it was renamed to `Display` * Many `Debug` and `Display` implementations were audited in accordance with the RFC and audited implementations now have the `#[stable]` attribute * Integers and floats no longer print a suffix * Smart pointers no longer print details that they are a smart pointer * Paths with `Debug` are now quoted and escape characters * The `unwrap` methods on `Result` now require `Display` instead of `Debug` * The `Error` trait no longer has a `detail` method and now requires that `Display` must be implemented. With the loss of `String`, this has moved into libcore. * `impl<E: Error> FromError<E> for Box<Error>` now exists * `derive(Show)` has been renamed to `derive(Debug)`. This is not currently warned about due to warnings being emitted on stage1+ While backwards compatibility is attempted to be maintained with a blanket implementation of `Display` for the old `String` trait (and the same for `Show`/`Debug`) this is still a breaking change due to primitives no longer implementing `String` as well as modifications such as `unwrap` and the `Error` trait. Most code is fairly straightforward to update with a rename or tweaks of method calls. [breaking-change] Closes #21436
2015-01-20 17:45:07 -06:00
impl<E:CLike + fmt::Debug> fmt::Debug for EnumSet<E> {
2014-09-13 19:37:03 -05:00
fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result {
try!(write!(fmt, "{{"));
2014-09-13 19:37:03 -05:00
let mut first = true;
2015-01-31 11:20:46 -06:00
for e in self {
2014-09-13 19:37:03 -05:00
if !first {
try!(write!(fmt, ", "));
}
try!(write!(fmt, "{:?}", e));
2014-09-13 19:37:03 -05:00
first = false;
}
write!(fmt, "}}")
}
}
2015-02-04 20:17:19 -06:00
/// An interface for casting C-like enum to usize and back.
/// A typically implementation is as below.
///
/// ```{rust,ignore}
2015-02-04 20:17:19 -06:00
/// #[repr(usize)]
/// enum Foo {
/// A, B, C
/// }
///
/// impl CLike for Foo {
2015-02-04 20:17:19 -06:00
/// fn to_usize(&self) -> usize {
/// *self as usize
/// }
///
2015-02-04 20:17:19 -06:00
/// fn from_usize(v: usize) -> Foo {
/// unsafe { mem::transmute(v) }
/// }
/// }
/// ```
pub trait CLike {
2015-02-04 20:17:19 -06:00
/// Converts a C-like enum to a `usize`.
fn to_usize(&self) -> usize;
/// Converts a `usize` to a C-like enum.
fn from_usize(usize) -> Self;
}
2015-02-04 20:17:19 -06:00
fn bit<E:CLike>(e: &E) -> usize {
use core::usize;
let value = e.to_usize();
2015-03-28 08:07:25 -05:00
assert!(value < usize::BITS,
2015-02-04 20:17:19 -06:00
"EnumSet only supports up to {} variants.", usize::BITS - 1);
1 << value
}
impl<E:CLike> EnumSet<E> {
/// Returns an empty `EnumSet`.
pub fn new() -> EnumSet<E> {
2015-02-12 09:38:21 -06:00
EnumSet {bits: 0, marker: marker::PhantomData}
}
2014-11-07 11:13:45 -06:00
/// Returns the number of elements in the given `EnumSet`.
2015-02-04 20:17:19 -06:00
pub fn len(&self) -> usize {
self.bits.count_ones() as usize
2014-11-07 11:13:45 -06:00
}
2014-08-04 05:48:39 -05:00
/// Returns true if the `EnumSet` is empty.
pub fn is_empty(&self) -> bool {
self.bits == 0
}
pub fn clear(&mut self) {
self.bits = 0;
}
/// Returns `false` if the `EnumSet` contains any enum of the given `EnumSet`.
pub fn is_disjoint(&self, other: &EnumSet<E>) -> bool {
(self.bits & other.bits) == 0
}
/// Returns `true` if a given `EnumSet` is included in this `EnumSet`.
pub fn is_superset(&self, other: &EnumSet<E>) -> bool {
(self.bits & other.bits) == other.bits
}
/// Returns `true` if this `EnumSet` is included in the given `EnumSet`.
pub fn is_subset(&self, other: &EnumSet<E>) -> bool {
2014-11-06 17:41:50 -06:00
other.is_superset(self)
}
2014-08-04 05:48:39 -05:00
/// Returns the union of both `EnumSets`.
pub fn union(&self, e: EnumSet<E>) -> EnumSet<E> {
2015-02-12 09:38:21 -06:00
EnumSet {bits: self.bits | e.bits,
marker: marker::PhantomData}
}
/// Returns the intersection of both `EnumSets`.
pub fn intersection(&self, e: EnumSet<E>) -> EnumSet<E> {
2015-02-12 09:38:21 -06:00
EnumSet {bits: self.bits & e.bits,
marker: marker::PhantomData}
}
/// Adds an enum to the `EnumSet`, and returns `true` if it wasn't there before
pub fn insert(&mut self, e: E) -> bool {
let result = !self.contains(&e);
self.bits |= bit(&e);
result
}
/// Removes an enum from the EnumSet
pub fn remove(&mut self, e: &E) -> bool {
let result = self.contains(e);
self.bits &= !bit(e);
result
}
/// Returns `true` if an `EnumSet` contains a given enum.
pub fn contains(&self, e: &E) -> bool {
(self.bits & bit(e)) != 0
}
2014-08-04 05:48:39 -05:00
/// Returns an iterator over an `EnumSet`.
pub fn iter(&self) -> Iter<E> {
Iter::new(self.bits)
}
}
2014-12-31 14:45:13 -06:00
impl<E:CLike> Sub for EnumSet<E> {
type Output = EnumSet<E>;
fn sub(self, e: EnumSet<E>) -> EnumSet<E> {
2015-02-12 09:38:21 -06:00
EnumSet {bits: self.bits & !e.bits, marker: marker::PhantomData}
}
}
2014-12-31 14:45:13 -06:00
impl<E:CLike> BitOr for EnumSet<E> {
type Output = EnumSet<E>;
fn bitor(self, e: EnumSet<E>) -> EnumSet<E> {
2015-02-12 09:38:21 -06:00
EnumSet {bits: self.bits | e.bits, marker: marker::PhantomData}
}
}
2014-12-31 14:45:13 -06:00
impl<E:CLike> BitAnd for EnumSet<E> {
type Output = EnumSet<E>;
fn bitand(self, e: EnumSet<E>) -> EnumSet<E> {
2015-02-12 09:38:21 -06:00
EnumSet {bits: self.bits & e.bits, marker: marker::PhantomData}
}
}
2014-12-31 14:45:13 -06:00
impl<E:CLike> BitXor for EnumSet<E> {
type Output = EnumSet<E>;
fn bitxor(self, e: EnumSet<E>) -> EnumSet<E> {
2015-02-12 09:38:21 -06:00
EnumSet {bits: self.bits ^ e.bits, marker: marker::PhantomData}
}
}
2013-07-25 23:53:29 -05:00
/// An iterator over an EnumSet
pub struct Iter<E> {
2015-02-04 20:17:19 -06:00
index: usize,
bits: usize,
2015-02-12 09:38:21 -06:00
marker: marker::PhantomData<E>,
}
// FIXME(#19839) Remove in favor of `#[derive(Clone)]`
impl<E> Clone for Iter<E> {
fn clone(&self) -> Iter<E> {
Iter {
index: self.index,
bits: self.bits,
2015-02-12 09:38:21 -06:00
marker: marker::PhantomData,
}
}
}
impl<E:CLike> Iter<E> {
2015-02-04 20:17:19 -06:00
fn new(bits: usize) -> Iter<E> {
2015-02-12 09:38:21 -06:00
Iter { index: 0, bits: bits, marker: marker::PhantomData }
}
}
2015-01-01 22:15:35 -06:00
impl<E:CLike> Iterator for Iter<E> {
type Item = E;
fn next(&mut self) -> Option<E> {
2014-01-19 02:21:14 -06:00
if self.bits == 0 {
return None;
}
while (self.bits & 1) == 0 {
self.index += 1;
self.bits >>= 1;
}
2015-02-04 20:17:19 -06:00
let elem = CLike::from_usize(self.index);
self.index += 1;
self.bits >>= 1;
Some(elem)
}
2015-02-04 20:17:19 -06:00
fn size_hint(&self) -> (usize, Option<usize>) {
let exact = self.bits.count_ones() as usize;
(exact, Some(exact))
}
}
impl<E:CLike> FromIterator<E> for EnumSet<E> {
fn from_iter<I: IntoIterator<Item=E>>(iter: I) -> EnumSet<E> {
let mut ret = EnumSet::new();
ret.extend(iter);
ret
}
}
#[stable(feature = "rust1", since = "1.0.0")]
impl<'a, E> IntoIterator for &'a EnumSet<E> where E: CLike {
type Item = E;
type IntoIter = Iter<E>;
fn into_iter(self) -> Iter<E> {
self.iter()
}
}
impl<E:CLike> Extend<E> for EnumSet<E> {
fn extend<I: IntoIterator<Item=E>>(&mut self, iter: I) {
for element in iter {
self.insert(element);
}
}
}
2015-06-03 05:38:42 -05:00
#[stable(feature = "extend_ref", since = "1.2.0")]
impl<'a, E: 'a + CLike + Copy> Extend<&'a E> for EnumSet<E> {
fn extend<I: IntoIterator<Item=&'a E>>(&mut self, iter: I) {
self.extend(iter.into_iter().cloned());
}
}