Apply latest clippy rules.

Author: daemontus

src/_impl_fn_update.rs

@@ -1124,10 +1124,7 @@ mod tests {
         ",
         )
         .unwrap();
-        let args = bn
-            .variables()
-            .map(|it| FnUpdate::mk_var(it))
-            .collect::<Vec<_>>();
+        let args = bn.variables().map(FnUpdate::mk_var).collect::<Vec<_>>();
         assert_eq!(
             FnUpdate::try_from_str("a & b & c", &bn).unwrap(),
             FnUpdate::mk_conjunction(&args)

src/biodivine_std/structs.rs

@@ -101,7 +101,7 @@ mod tests {
         assert!(!state.get_bit(3));
         assert!(state.get_bit(4));
         let flipped = state.flip_bit(3);
-        assert_eq!(0b11110 as usize, flipped.into());
+        assert_eq!(0b11110_usize, flipped.into());
     }
 
     #[test]

src/lib.rs

@@ -4,7 +4,7 @@
 //!  - Full SBML-qual support for import/export as well as custom string format `.aeon`.
 //!  - Fully symbolic asynchronous state-space generator using BDDs (great overall performance).
 //!  - Semi-symbolic state-space generator, using BDDs used only for the network parameters
-//! (allows state-level parallelism for smaller networks).
+//!    (allows state-level parallelism for smaller networks).
 //!
 //! For a quick introduction to Boolean networks and their symbolic manipulation, you can
 //! check out our [tutorial module](./tutorial/index.html).
@@ -155,10 +155,10 @@ pub struct Parameter {
 /// Every regulation can be *monotonous*, and can be set as *observable*:
 ///
 ///  - Monotonicity is either *positive* or *negative* and signifies that the influence of the
-/// `regulator` on the `target` has to *increase* or *decrease* the `target` value respectively.
+///    `regulator` on the `target` has to *increase* or *decrease* the `target` value respectively.
 ///  - If observability is set to `true`, the `regulator` *must* have influence on the outcome
-///  of the `target` update function in *some* context. If set to false, this is not enforced
-///  (i.e. the `regulator` *can* have an influence on the `target`, but it is not required).
+///    of the `target` update function in *some* context. If set to false, this is not enforced
+///    (i.e. the `regulator` *can* have an influence on the `target`, but it is not required).
 ///
 /// Regulations can be represented as strings in the
 /// form `"regulator_name 'relationship' target_name"`. The 'relationship' starts with `-`, which

src/symbolic_async_graph/_impl_symbolic_async_graph.rs

@@ -334,7 +334,7 @@ impl SymbolicAsyncGraph {
     ///
     /// *Note:* The reason this method takes a slice and not, e.g., a `HashMap` is that:
     ///  - If constant, slices are much easier to write in code (i.e. we can write
-    /// `graph.mk_subspace(&[(a, true), (b, false)])` -- there is no such syntax for a map).
+    ///    `graph.mk_subspace(&[(a, true), (b, false)])` -- there is no such syntax for a map).
     ///  - This is already used by the internal BDD API, so the conversion is less involved.
     pub fn mk_subspace(&self, values: &[(VariableId, bool)]) -> GraphColoredVertices {
         let partial_valuation: Vec<(BddVariable, bool)> = values
@@ -603,12 +603,12 @@ impl SymbolicAsyncGraph {
     /// checking algorithms:
     ///  - The two networks have the same variables.
     ///  - All parameters used in the subnetwork must also be declared in the
-    ///  main network (with the same arity).
+    ///    main network (with the same arity).
     ///  - The regulations are identical in both networks (including monotonicity/observability).
     ///  - If the main network has an update function, the subnetwork must have the same
-    ///  update function (tested using the abstract syntax tree, not semantics).
+    ///    update function (tested using the abstract syntax tree, not semantics).
     ///  - If the main network has an erased update function, the subnetwork can have
-    ///  a fully specified function (no parameters) instead.
+    ///    a fully specified function (no parameters) instead.
     ///  - The subnetwork and main network are consistent with the shared regulatory graph.
     ///
     /// If all of these conditions are met, the function returns a `ColorSet` representing all
@@ -830,7 +830,7 @@ impl SymbolicAsyncGraph {
     ///
     /// The `graph` is considered compatible if:
     ///  1. All parameters which appear in `colors` also appear in this graph under the same name
-    ///  (parameters not used in `colors` do not matter).
+    ///     (parameters not used in `colors` do not matter).
     ///  2. The internal ordering of symbolic parameter variables is equivalent between graphs.
     ///
     /// At the moment, condition (2) depends on network structure and is hard to directly
@@ -853,7 +853,7 @@ impl SymbolicAsyncGraph {
     ///
     /// The `graph` is considered compatible if:
     ///  1. All variables which appear in `vertices` also appear in this graph under the same name
-    ///  (variables not used in `vertices` do not matter).
+    ///     (variables not used in `vertices` do not matter).
     ///  2. The internal ordering of symbolic variables is equivalent between the two graphs.
     ///
     /// At the moment, variables are by default ordered alphabetically, hence condition (2)
@@ -876,7 +876,7 @@ impl SymbolicAsyncGraph {
     ///
     /// The `graph` is considered compatible if:
     ///  1. All parameters and state variables which appear in `set` also appear in this graph
-    ///  under the same name (variables not used in `set` do not matter).
+    ///     under the same name (variables not used in `set` do not matter).
     ///  2. The internal ordering of relevant symbolic variables is equivalent between graphs.
     ///
     /// At the moment, condition (2) depends on network structure and is hard to directly

src/symbolic_async_graph/mod.rs

@@ -233,7 +233,7 @@ mod tests {
                 universe = universe.minus(&scc);
                 components.push(scc);
             }
-            return components;
+            components
         }
         let bn = BooleanNetwork::try_from(
             r"