Clippy doc lint

Author: maneatingape

src/util/grid.rs

@@ -17,9 +17,9 @@
 //! ```
 //!
 //! A convenience [`parse`] method creates a `Grid` directly from a 2 dimenionsal set of
-//! ASCII characters, a common occurence in AoC inputs. The [`default_copy`] function creates a
-//! grid of the same size, that can be used for in BFS algorithms for tracking visited location
-//! or for tracking cost in Djikstra.
+//! ASCII characters, a common occurence in Advent of Code inputs. The [`default_copy`] function
+//! creates a grid of the same size, that can be used for in BFS algorithms for tracking visited
+//! location or for tracking cost in Djikstra.
 //!
 //! [`Point`]: crate::util::point
 //! [`parse`]: Grid::parse

src/util/parse.rs

@@ -1,14 +1,15 @@
 //! Extracts and parses signed and unsigned integers from surrounding text and whitespace.
 //!
-//! A common pattern in AoC is to parse and return `123`, `456` and `789` from input resembling:
+//! A common pattern in Advent of Code is to parse and return `123`, `456` and `789` from input
+//! resembling:
 //!
 //! ```none
 //!   Lorem ipsum 123 dolor 456 sit 789 amet
 //! ```
 //!
 //! This module provides two [`&str`] extension methods [`iter_signed`] and [`iter_unsigned`]. The
-//! reason for the separate methods is that some AoC inputs contains the `-` character as a
-//! delimeter and this would cause numbers to be incorrectly parsed as negative.
+//! reason for the separate methods is that some Advent of Code inputs contains the `-` character
+//! as a delimeter and this would cause numbers to be incorrectly parsed as negative.
 //!
 //! [`iter_unsigned`]: ParseOps::iter_unsigned
 //! [`iter_signed`]: ParseOps::iter_signed

src/util/point.rs

@@ -1,8 +1,8 @@
 //! Comprehensive 2 dimensional point implementation. This class is designed to work together
 //! with the [`Grid`] class.
 //!
-//! A common theme in AoC is operations in 2 dimensions. This module provides a [`Point`] struct
-//! along with implementations of several of the [`std::ops`] traits to support
+//! A common theme in Advent of Code is operations in 2 dimensions. This module provides a
+//! [`Point`] struct along with implementations of several of the [`std::ops`] traits to support
 //! operator overloading, that allows shorthand expressions such as:
 //!
 //! ```

src/year2015/day10.rs

@@ -1,7 +1,7 @@
 //! # Elves Look, Elves Say
 //!
 //! There is a trick to solve this problem in constant time and space. While this is not possible
-//! for any arbitrary sequence, in AoC *we only need to solve for our given input*.
+//! for any arbitrary sequence, in Advent of Code *we only need to solve for our given input*.
 //!
 //! Examining the input shows that it consists of one of Conway's
 //! [atomic elements](https://en.wikipedia.org/wiki/Look-and-say_sequence#Cosmological_decay).

src/year2020/day03.rs

@@ -1,7 +1,7 @@
 //! # Toboggan Trajectory
 //!
-//! Two dimensional grids of ASCII characters are a common AoC theme, so we use our utility
-//! [`Grid`] class to parse the data.
+//! Two dimensional grids of ASCII characters are a common Advent of Code theme,
+//! so we use our utility [`Grid`] class to parse the data.
 //!
 //! [`Grid`]: crate::util::grid
 use crate::util::grid::*;

src/year2020/day19.rs

@@ -49,7 +49,7 @@
 //!
 //! For example `42 42 31` or `42 42 42 31` or `42 42 42 31 31` matches but *not* `42 42 31 31`.
 //!
-//! Since we don't need to handle the general input case (a common pattern in AoC) we can
+//! Since we don't need to handle the general input case (a common pattern in Advent of Code) we can
 //! implement this rule directly in code.
 use crate::util::parse::*;
 use Rule::*;

src/year2020/day22.rs

@@ -5,7 +5,7 @@
 //! circular buffer. Why use our own implementation when there is a perfectly good [`VecDeque`]
 //! already available? The answer is speed. As there are at most fifty cards in the pack, the Deck
 //! can use a fix sized stack allocated array, avoiding the expensive heap allocations that
-//! VecDeque must use.
+//! [`VecDeque`] must use.
 //!
 //! `Deck` also keeps the score up to date as cards are added and removed, as this comes in useful
 //! during part two. To update the score when a card is removed we subtract the card's value

src/year2021/day02.rs

@@ -1,8 +1,8 @@
 //! # Dive!
 //!
 //! Both part 1 and part 2 rely on the [`fold`] method. This method comes in useful for a lot
-//! of AoC problems so is handy to know about. The input is parsed into a tuple enum [`Sub`] for
-//! convenience.
+//! of Advent of Code problems so is handy to know about. The input is parsed into a tuple enum
+//! [`Sub`] for convenience.
 //!
 //! [`fold`]: Iterator::fold
 use crate::util::iter::*;

src/year2021/day09.rs

@@ -7,8 +7,8 @@
 //! such as a [`VecDeque`].
 //!
 //! This solution uses a DFS approach as it's faster and Rust's stack size limit seems enough
-//! to accommodate the maximum basin size. 2 dimensional grids are common in AoC problems so we
-//! use our utility [`Grid`] and [`Point`] modules.
+//! to accommodate the maximum basin size. 2 dimensional grids are common in Advent of Code
+//! problems so we use our utility [`Grid`] and [`Point`] modules.
 //!
 //! [`VecDeque`]: std::collections::VecDeque
 //! [`Grid`]: crate::util::grid

src/year2022/day04.rs

@@ -24,7 +24,7 @@ type Pairs = [u32; 4];
 /// Parse each line into 4 integers.
 ///
 /// Notes:
-/// * Extracting integers from redundant text is a very common theme in AoC that
+/// * Extracting integers from redundant text is a very common theme in Advent of Code that
 ///   the [`iter_unsigned`] method handles.
 ///
 /// [`iter_unsigned`]: ParseOps::iter_unsigned

src/year2022/day06.rs

@@ -15,7 +15,7 @@
 ///
 /// Notes:
 /// * We need to [`trim`] to remove the trailing newline character
-/// * AoC input is always ASCII characters, so casting to an `u8` slice is acceptable.
+/// * Advent of Code input is always ASCII characters, so casting to an `u8` slice is acceptable.
 ///
 /// [`trim`]: str::trim
 pub fn parse(input: &str) -> Vec<usize> {

src/year2022/day07.rs

@@ -1,7 +1,7 @@
 //! # No Space Left On Device
 //!
 //! Some up-front analysis of the input data helps us develop an efficient solving algorithm (this
-//! is a regular theme in AoC!). Looking at the directory commands shows 2 key insights:
+//! is a regular theme in Advent of Code!). Looking at the directory commands shows 2 key insights:
 //! * We never return to a previously visited directory
 //! * Directory traversal is only up or down in steps of one.
 //!

src/year2022/day09.rs

@@ -1,7 +1,8 @@
 //! # Rope Bridge
 //!
-//! This solution relies on the [`Point`] utility class. Two dimensional problems are common in AoC,
-//! so having a decent `Point` (or `Coord` or `Pos`) class in your back pocket is handy.
+//! This solution relies on the [`Point`] utility class. Two dimensional problems are common in
+//! Advent of Code, so having a decent `Point` (or `Coord` or `Pos`) class in your back pocket
+//! is handy.
 use crate::util::iter::*;
 use crate::util::parse::*;
 use crate::util::point::*;

src/year2022/day11.rs

@@ -1,8 +1,8 @@
 //! # Monkey in the Middle
 //!
-//! This problem is the combination of 2 AoC classics, extracting numbers from a wall of
-//! flavor text and modular arithmetic. For the first problem, our utility [`iter_unsigned`] method
-//! comes in handy.
+//! This problem is the combination of two Advent of Code classics, extracting numbers from a wall
+//! of flavor text and modular arithmetic. For the first problem, our utility [`iter_unsigned`]
+//! method comes in handy.
 //!
 //! For the second problem, the key insight for part 2 is that
 //! `a % m` is the same as `(a % n) % m` if `m` is a factor of `n`.

src/year2022/day12.rs

@@ -2,7 +2,7 @@
 //!
 //! Pretty much textbook implementation of a BFS (Breadth First Search). If you're not familar with
 //! BFS, [this blog post is a great introduction](https://www.redblobgames.com/pathfinding/a-star/introduction.html)
-//! to the algorithm, plus some others that come in handy for AoC.
+//! to the algorithm, plus some others that come in handy for Advent of Code.
 //!
 //! Implementation notes:
 //! * A [`VecDeque`] of [`Point`] is used to store the frontier as it gives better performance