Advent of Code 2023 | Live and let Learn

Day03 Tokens, Enums and Docstrings

Fri, 12 Jan 2024 06:45:18 +1100

The Day 03 challenge involves the calculating whether a character symbol is adjacent to a part number in a two dimensional map, such as:

467..114..
...*......
..35..633.
......#...
617*......
.....+.58.
..592.....
......755.
...$.*....
.664.598..

and then doing things with the part numbers.

To calculate whether a symbol is adjacent to a part number we’re going to need:

the position of each symbol,
the position of each number,
the length of the token for each number.

Tokenising the input

The simplest way to get this data that I can think of is to parse the map into a list of tokens, where the number and blank tokens contain the info for me to know the length (ie. the &str).

There are four different types of tokens in our input:

#[derive(Debug, PartialEq)]
pub enum Token<'a> {
 Number(&'a str),
 Symbol(char),
 Blank(&'a str),
 NewLine,
}

This looks like a job for nom again, so we create a set of parsers that parse each of the above, and combine them in a single parse function that parses the input into a vector of tokens.

Note, this time, rather than using test_case to write separate test cases for each function, I’m instead using doctests as I think they communicate more clearly the intent of the code as they remain in the context of the code:

///
/// Parses a number token
///
/// ```
/// # use aoc::{parse_number, Token};
/// let result = parse_number("123..*.456");
/// assert_eq!(result, Ok(("..*.456", Token::Number("123"))));
/// ```
pub fn parse_number(input: &str) -> IResult<&str, Token> {
 map(recognize(digit1), |n: &str| Token::Number(n))(input)
}

///
/// Parses a symbol token
///
/// ```
/// # use aoc::{parse_symbol_token, Token};
/// let result = parse_symbol_token("*?..456");
/// assert_eq!(result, Ok(("?..456", Token::Symbol('*'))));
/// ```
pub fn parse_symbol_token(input: &str) -> IResult<&str, Token> {
 map(one_of("*#+$?/&-=%@"), Token::Symbol)(input)
}

///
/// Parses a blank token
///
/// ```
/// # use aoc::{parse_blank, Token};
/// let result = parse_blank("...456");
/// assert_eq!(result, Ok(("456", Token::Blank("..."))));
/// ```
pub fn parse_blank(input: &str) -> IResult<&str, Token> {
 map(recognize(many1(tag("."))), |s: &str| Token::Blank(s))(input)
}

pub fn parse_newline(input: &str) -> IResult<&str, Token> {
 map(tag("\n"), |_| Token::NewLine)(input)
}

pub fn parse_token(input: &str) -> IResult<&str, Token> {
 alt((parse_number, parse_symbol_token, parse_blank, parse_newline))(input)
}

With this, we can now parse the input into a vector of tokens with:

///
/// Parses text into a vector of Tokens
///
/// ```
/// # use aoc::{parse, Token};
/// let result = parse("123..*.456\n987...");
/// assert_eq!(
/// result,
/// Ok((
/// "",
/// vec![
/// Token::Number("123"),
/// Token::Blank(".."),
/// Token::Symbol('*'),
/// Token::Blank("."),
/// Token::Number("456"),
/// Token::NewLine,
/// Token::Number("987"),
/// Token::Blank("..."),
/// ]
/// ))
/// );
/// ```
pub fn parse(input: &str) -> IResult<&str, Vec<Token>> {
 many1(parse_token)(input)
}

Part 1: the sum of parts

Now that we’ve got the data tokenised, we can translate the tokens into the data structures that will help us solve the question. For part 1, it involves summing all the part numbers, but

apparently any number adjacent to a symbol, even diagonally, is a “part number” and should be included in your sum

while the other numbers are to be ignored. So we need to be able test, for each number, if it is adjacent to a symbol, which in turn requires testing if a position contains a symbol.

Testing for a symbol at a certain position

So the first step here is to translate our vector of tokens into a symbol map, a HashMap<Position, char>, that we can use to test if a certain position has a symbol.

#[derive(Debug, Clone, Copy, Hash, PartialEq, Eq)]
pub struct Position {
 x: i32,
 y: i32,
}
impl Position {
 pub fn new(x: i32, y: i32) -> Self {
 Self { x, y }
 }
}

///
/// Converts a vector of Tokens into a HashMap of Positions to symbols
///
/// ```
/// # use aoc::{parse, Token, tokens_to_symbol_map, Position};
/// # use std::collections::HashMap;
/// let (_, tokens) = parse("123..*.456\n987.?.").unwrap();
/// assert_eq!(
/// tokens_to_symbol_map(&tokens),
/// HashMap::from_iter(
/// vec![
/// (Position::new(5, 0), '*'),
/// (Position::new(4, 1), '?'),
/// ]
/// )
/// );
pub fn tokens_to_symbol_map(tokens: &Vec<Token>) -> HashMap<Position, char> {
 let mut symbol_map = HashMap::new();
 let mut x = 0;
 let mut y = 0;
 for token in tokens {
 match token {
 Token::Number(l) => {
 x += l.len() as i32;
 }
 Token::Symbol(s) => {
 symbol_map.insert(Position { x, y }, *s);
 x += 1;
 }
 Token::Blank(b) => {
 x += b.len() as i32;
 }
 Token::NewLine => {
 x = 0;
 y += 1;
 }
 }
 }
 symbol_map
}

Iterating a vector of parts

The other data we need is a vector of engine parts - a position and a &str label:

#[derive(Debug, PartialEq)]
pub struct EnginePart<'a> {
 label: &'a str,
 position: Position,
}
impl<'a> EnginePart<'a> {
 pub fn new(label: &'a str, position: Position) -> Self {
 Self { label, position }
 }
}

///
/// Converts a vector of Tokens into a vector of EngineParts with positions
///
/// ```
/// # use aoc::{parse, Token, tokens_to_engine_parts, EnginePart, Position};
/// let (_, tokens) = parse("123..*.456\n987...").unwrap();
/// assert_eq!(
/// tokens_to_engine_parts(&tokens),
/// vec![
/// EnginePart::new("123", Position::new(0, 0)),
/// EnginePart::new("456", Position::new(7, 0)),
/// EnginePart::new("987", Position::new(0, 1)),
/// ]
/// );
pub fn tokens_to_engine_parts<'a>(tokens: &'a Vec<Token<'a>>) -> Vec<EnginePart<'a>> {
 let mut engine_parts = Vec::new();
 let mut x = 0;
 let mut y = 0;
 for token in tokens {
 match token {
 Token::Number(l) => {
 engine_parts.push(EnginePart {
 label: l,
 position: Position { x, y },
 });
 x += l.len() as i32;
 }
 Token::Symbol(_) => {
 x += 1;
 }
 Token::Blank(b) => {
 x += b.len() as i32;
 }
 Token::NewLine => {
 x = 0;
 y += 1;
 }
 }
 }
 engine_parts
}

Checking if an engine part is adjacent to a symbol

For a specific EnginePart, we can list the positions adjacent to it by defining a rectangle one unit larger than the number token, then checking if an engine part is adjacent to a symbol is simply checking if any adjacent position is a key in the symbol map:


impl<'a> EnginePart<'a> {
 ...

 pub fn adjacent_positions(&self) -> Vec<Position> {
 // The following calculates the range of positions that compose
 // the area around the number. This is a rectangle that is one
 // unit larger than the number in each direction.
 // This will include the position of the number itself, but that's fine.
 let mut adjacent_positions = Vec::new();
 ((self.position.x - 1)..=(self.position.x + self.label.len() as i32)).for_each(|x| {
 ((self.position.y - 1)..=(self.position.y + 1)).for_each(|y| {
 adjacent_positions.push(Position::new(x, y));
 });
 });
 adjacent_positions
 }

 pub fn adjacent_to_symbol(&self, symbol_map: &HashMap<Position, char>) -> bool {
 self.adjacent_positions()
 .iter()
 .any(|p| symbol_map.contains_key(p))
 }

and with that, our part 1 binary can just parse and sum the engine parts that are adjacent to a symbol:

use std::error::Error;

use aoc::{parse, tokens_to_engine_parts, tokens_to_symbol_map};

fn main() -> Result<(), Box<dyn Error>> {
 let input = include_str!("../../input.txt");
 let (rest, tokens) = parse(input)?;
 assert_eq!(rest, "");

 let engine_parts = tokens_to_engine_parts(&tokens);

 let symbol_map = tokens_to_symbol_map(&tokens);

 let sum_of_engine_parts = engine_parts
 .iter()
 .filter(|ep| ep.adjacent_to_symbol(&symbol_map))
 .map(|ep| ep.label().parse::<u32>().unwrap())
 .sum::<u32>();
 dbg!(sum_of_engine_parts);
 Ok(())
}

Part 2: Gear ratios

Part 2 for this day has us checking for special symbols, gears *, that are adjacent to exactly two parts:

A gear is any * symbol that is adjacent to exactly two part numbers. Its gear ratio is the result of multiplying those two numbers together.

This time, you need to find the gear ratio of every gear and add them all up so that the engineer can figure out which gear needs to be replaced.

Well, that didn’t take much more work…we can check if a position is adjacent to an Engine part with the following:

impl<'a> EnginePart<'a> {
 ...
 ///
 /// Returns true if the given position is adjacent to this EnginePart
 ///
 /// ```
 /// # use aoc::{EnginePart, Position};
 /// let engine_part = EnginePart::new("114", Position::new(5, 0));
 /// assert!(engine_part.adjacent_to_pos(Position::new(4, 1)));
 /// assert!(!engine_part.adjacent_to_pos(Position::new(3, 1)));
 /// ```
 pub fn adjacent_to_pos(&self, pos: Position) -> bool {
 self.adjacent_positions().iter().any(|p| p == &pos)
 }
}

and with that, solve part 2 with the binary:

use std::error::Error;

use aoc::{parse, tokens_to_engine_parts, tokens_to_symbol_map, EnginePart};

fn main() -> Result<(), Box<dyn Error>> {
 let input = include_str!("../../input.txt");
 let (rest, tokens) = parse(input)?;
 assert_eq!(rest, "");

 let engine_parts = tokens_to_engine_parts(&tokens);

 let symbol_map = tokens_to_symbol_map(&tokens);

 let sum_of_gear_ratios = symbol_map
 .iter()
 // We only want the positions of the gear characters...
 .filter_map(|(p, s)| match s {
 '*' => Some(p),
 _ => None,
 })
 // and then, only want the gear ratios of those with exactly
 // two adjacent parts
 .filter_map(|p| {
 let adjacent_parts = engine_parts
 .iter()
 .filter(|ep| ep.adjacent_to_pos(*p))
 .collect::<Vec<&EnginePart>>();
 match adjacent_parts.len() {
 2 => Some(
 adjacent_parts[0].label().parse::<u32>().unwrap()
 * adjacent_parts[1].label().parse::<u32>().unwrap(),
 ),
 _ => None,
 }
 })
 .sum::<u32>();

 dbg!(sum_of_gear_ratios);
 Ok(())
}

Our binary for part 2 is a little more complicated, but it’s nice not having to change much of the existing library code to solve part 2.

Day02 Copilot and Vanilla Parsing

Sun, 07 Jan 2024 06:13:31 +1100

After refreshing my knowledge of the rust parsing library ’nom’ with the day01 challenge, I was keen to do the second challenge without, simply using the standard library’s string manipulation and default parsing for this simpler parsing problem.

At the same time, I was keen to work more with GitHub Copilot since I’ve not been able to use copilot at my most recent job due to potential legal issues.

The Elf’s game for day 02 consists of pulling out multiple combinations of red, green and blue balls from a sack - and the parsing looks quite straight forward.

What did I learn from this challenge? This one was pretty straight forward (simpler than the day01 parsing challenge) and a good chance to solve without any imports other than std::error::Error. What I learned was how copilot and similar technology can make programming even more fun by suggesting a lot of boiler plate when you express your intent clearly.

Parsing the data without nom

Each game has an id and a number of rounds:

Game 1: 3 blue, 4 red; 1 red, 2 green, 6 blue; 2 green

Starting with the “3 blue”, a number associated with one of three colours, an enum is rust seemed most appropriate (given that Rust enum variants can contain data):

// A Cube represensts a colour and how many times it appears
#[derive(Clone, Copy, Debug, PartialEq)]
enum Cube {
 Red(u32),
 Green(u32),
 Blue(u32),
}

I then began with some failing test cases, which copilot helped make much less tedious, suggesting most of the boiler plate:

 #[test_case("1 red", Ok(Cube::Red(1)); "Cube parsing red")]
 #[test_case("28 green", Ok(Cube::Green(28)); "Cube parsing green")]
 #[test_case("99 blue", Ok(Cube::Blue(99)); "Cube parsing blue")]
 #[test_case("1", Err("Invalid cube: incorrect number of parts"); "Cube parsing invalid")]
 fn test_cube_from_str(input: &str, want: Result<Cube, &'static str>) {
 assert_eq!(Cube::try_from(input), want);
 }

and then began implementing the TryFrom<&str> trait and again had copilot do most of the boring boiler plate, which after a few small tweaks, enabled tests to pass:

// Parse "3 red" into Cube::Red(3)
impl TryFrom<&str> for Cube {
 type Error = &'static str;

 fn try_from(value: &str) -> Result<Self, Self::Error> {
 let parts: Vec<_> = value.split_ascii_whitespace().collect();
 if parts.len() != 2 {
 return Err("Invalid cube: incorrect number of parts");
 };
 let (num, colour) = (parts[0], parts[1]);

 let num = num
 .parse::<u32>()
 .map_err(|_| "Invalid cube: error parsing integer")?;

 match colour {
 "red" => Ok(Cube::Red(num)),
 "green" => Ok(Cube::Green(num)),
 "blue" => Ok(Cube::Blue(num)),
 _ => Err("Invalid cube: unsupported colour"),
 }
 }
}

The process for the parsing a set of coloured cubes:

// A CubeSet is a set of cubes with a count of how many of each colour
// E.g. "3 blue, 4 red"
#[derive(Clone, Copy, Debug, PartialEq)]
pub struct CubeSet {
 red: u32,
 green: u32,
 blue: u32,
}

and a game of multiple sets:

// A Game has an id and a list of CubeSets
// such as "Game 1: 3 blue, 4 red; 5 green, 6 blue" into
#[derive(Clone, Debug, PartialEq)]
pub struct Game {
 pub id: u32,
 cubesets: Vec<CubeSet>,
}

was so similar, it’s not worth repeating.

Part 1: which games are possible for a given set of cubes

The first problem says

The Elf would first like to know which games would have been possible if the bag contained only 12 red cubes, 13 green cubes, and 14 blue cubes?

with the answer being the sum of the valid games. OK, so a game is only valid for a particular cube set, if each cubset of the game is also valid. And according to the Elf, a particular set of cubes is only possible if it does not have more of a certain colour than the set he provides, so:

impl Game {
 // Return whether the game (a list of cubesets) is valid for a given Cubeset.
 pub fn is_valid(&self, cubeset: &CubeSet) -> bool {
 self.cubesets.iter().map(|c| c.is_valid(cubeset)).all(|v| v)
 }
 ...
}

impl CubeSet {
 // Return whether this CubeSet can be pulled out of a bag that contains the
 // given CubeSet.
 pub fn is_valid(&self, cubeset: &CubeSet) -> bool {
 self.blue <= cubeset.blue && self.green <= cubeset.green && self.red <= cubeset.red
 }

and with those, part 1 is solved by mapping the valid games to sum the game id’s, without external imports other than std::error::Error:

use aoc::{CubeSet, Game};
use std::error::Error;

fn main() -> Result<(), Box<dyn Error>> {
 let elf_cubeset = CubeSet::new(12, 13, 14);

 // For each line in the input file, parse and map line of text to a parsed
 // Game.
 let valid_games_sum: u32 = include_str!("../../input.txt")
 .lines()
 .map(|line| Game::try_from(line).expect("each line should have a valid game"))
 .filter(|game| game.is_valid(&elf_cubeset))
 .map(|game| game.id)
 .sum();

 println!("Part 1 sum of valid games is {}", valid_games_sum);

 Ok(())
}

Part 2: fewest cubes per game

The second part to the day’s problem is only a little trickier, requiring for each game (a list of cube sets), we calculate the minimum cubeset - that is, the minimum number of cubes of each colour for that game to be possible. This is a nice way to see the default Rust reduce/fold functionality to iterate through the list of cubesets and remember the minimum number of cubes:


impl Game {
 ...
 // Return the minimum cubeset that could be used for all rounds of a game.
 pub fn min_cubeset(&self) -> CubeSet {
 self.cubesets
 .iter()
 .fold(CubeSet::new(0, 0, 0), |acc, &c| CubeSet {
 red: acc.red.max(c.red),
 green: acc.green.max(c.green),
 blue: acc.blue.max(c.blue),
 })
 }
}

To provide an answer to the problem, we need to sum the “power” of each minimum cubeset, where the power is just:

impl CubeSet {
 ...
 // pow returns the num red * num green * num blue for a cubeset
 pub fn pow(&self) -> u32 {
 self.red * self.green * self.blue
 }
}

enabling the part 2 solution to map each minimum cubeset to the power and sum them, again without any external imports other than std::error::Error:

use aoc::Game;
use std::error::Error;

fn main() -> Result<(), Box<dyn Error>> {
 // Game.
 let sum_game_pows: u32 = include_str!("../../input.txt")
 .lines()
 .map(|line| Game::try_from(line).expect("each line should have a valid game"))
 .map(|game| game.min_cubeset())
 .map(|c| c.pow())
 .sum();

 println!("Part 1 sum of game powers is {}", sum_game_pows);

 Ok(())
}

Pretty straight-forward once simple data structures are chosen and the data parsed.

Day 01 - a Rust Parsing Exercise With Nom

Sun, 10 Dec 2023 13:51:15 +1100

It’s been quite some time since I’ve taken time to enjoy coding challenges primarily for the fun of it. Over the next months, I’m keen to work my way through the 2023 Advent of Code - a fun set of problems created by Eric Wastl strung together with a seasonal story - and write up a bit about my own learning and fun.

For me it’s a chance to keep improving my fluency with various Rust libraries and tools (start learning the Rust programming language here!). And the first day of the 2023 Advent of Code is a parsing exercise - a good opportunity to re-familiarise myself with Rust’s nom parsing library as well as re-enforce in my head that confirmation bias is strong in this one (me).

For this first problem, day 1, I’m just going to outline the final solutions that I arrived at and note, for my own learning, where I was tripped up, whereas I’ll plan my commits a little better for the rest of the problems to learn also from the path I’ve taken (thanks to Amos at fasterthanli.me for the inspiration to start writing about what I learn again).

So first, the actual binary main functions for parts 1 and 2 are similar and straight-forward:

use aoc::parse_calibration_part1;
use std::error::Error;

fn main() -> Result<(), Box<dyn Error>> {
 // For each line in the input file, parse and map line of text to a parsed
 // calibration value.
 let calibrations: Vec<_> = include_str!("../../input.txt")
 .lines()
 .map(|line| {
 let (_, calibration) =
 parse_calibration_part1(line).expect("each line should have a valid calibration");
 calibration
 })
 .collect();

 // We don't need to collect the iteration values back into a vec above,
 // to then turn it back into an iterator below to sum, but it's
 // handy for debugging, so I've left it as is.

 println!(
 "Sum of calibrations is {}",
 calibrations.into_iter().sum::<u32>()
 );

 Ok(())
}

differing only in that part2 calls parse_calibration_part2() instead.

Part 1 - A calibration value using the first and last digits

The first part of the challenge is to parse the first and last digit when given a string of alphanumeric characters. So a string such as “a1b2c3d4e45f” is parsed as the number 15. Each such line gives a calibration value, with the desired result being the summation of all calibrations for all lines of your input.

I find it useful to add an initial implementation with a todo!():

pub fn parse_calibration_part1(input: &str) -> IResult<&str, u32> {
 todo!("Start here...");
}

so that I can go ahead and write a bunch of failing test cases before hitting confirmation bias as I implement and test further (and no, I didn’t come up with all of these before writing - the last one is the result of noticing that I’d missed this explicit case even though it’d been highlighted in the instructions):

#[cfg(test)]
mod tests {
 use super::*;
 use test_case::test_case;

 #[test_case("1abc2", Ok(("", 12)); "extracts first and last from line")]
 #[test_case("11abc24", Ok(("", 14)); "extracts first and last digits from multidigit numbers on line")]
 #[test_case("11a3399bc24", Ok(("", 14)); "extracts first and last digits from numbers on line ignoring other numbers")]
 #[test_case("pqr3stu8vwx", Ok(("", 38)); "extracts first and last digits from numbers on line ignoring prefix alphas")]
 #[test_case("treb7uchet", Ok(("", 77)); "extracts first and last digits from numbers when only one digit")]
 fn test_parse_calibration_part1(input: &str, want: IResult<&str, u32>) {
 assert_eq!(parse_calibration_part1(input), want);
 }

 ...

Part 1 Step 1 - parsing the numbers amongst alpha characters

Nom is a parsing library that allows building combinators of parsers. In this case, we want to:

capture at least one but possibly many numbers that may be preceeded or terminated with zero or more alpha characters to get a result such as vec!["26", "45", "98"] (line 6 below),
map that result through a function to take the first digit of the first number and the last digit of the last number, eg. 28 for the example above (line 7 below)

// Parsing the line for the calibration in part one is recognising and
// extracting numbers made of digits, then returning the first digit of the
// first number and the last digit of the last number.
pub fn parse_calibration_part1(input: &str) -> IResult<&str, u32> {
 map(
 many1(preceded(alpha0, terminated(digit1, alpha0))),
 |multidigits: Vec<&str>| first_n_last(multidigits),
 )(input)
}

In this case I just moved my todo(); into a stubbed first_n_last function.

Part 1 Step 2 - first and list digits

Extracting the first and last digits of a vec of numbers to form a new base 10 number is just an exercise in learning/using rust’s excellent built-in methods:

// first_n_last extracts the first digit of the first number in
// a vec of string numbers, together with the last digit of the
// last number.
// So for example, example: given the input vec!["24", "32", "98"],
// the resulting calibration is "28".
fn first_n_last(multidigits: Vec<&str>) -> u32 {
 // First character of the first number string,
 // parsed base 10.
 let first = multidigits
 .first()
 .expect("must be at least one number on a line")
 .chars()
 .nth(0)
 .expect("must be at least one digit in a number")
 .to_digit(10)
 .expect("should be base 10 digit");
 // Last character of the last number string, parsed base 10
 let last = multidigits
 .last()
 .expect("must be at least one number on a line")
 .chars()
 .last()
 .expect("must be at least one digit in a number")
 .to_digit(10)
 .unwrap();
 first * 10 + last
}

Tests pass, the example input works, and when run with my own input, I get my first star. Happy days, until…

Part 2 - including digits spelled out with letters

OK, I admit, initially I thought part 2 would be a trivial addition but I failed to take into account my brain’s tendancy to confirm the first solution it finds.

I knew I wanted to reuse my first_n_last function, and simply have a new parse_digits function which would parse both digits and spelled-out words representing digits, so I started with a stubbed (todo!()) parse_digits function and a few test cases of what I expect to see:

 #[test_case("two14", Ok(("", vec!["2", "14"])); "extracts word digit to digit")]
 #[test_case("atwo14", Ok(("", vec!["2", "14"])); "extracts word digit to digit with prefix alpha")]
 #[test_case("atwoa1heightu4", Ok(("", vec!["2", "1", "8", "4"])); "extracts word digit to digit with prefix and postfix alpha")]
 #[test_case("two1nine", Ok(("", vec!["2", "1", "9"])); "extracts word digit and digits together")]
 #[test_case("atwoa1heightu48", Ok(("", vec!["2", "1", "8", "48"])); "extracts word digit to digit with prefix and multi-digit")]
 #[test_case("atwoa1sevenine", Ok(("", vec!["2", "1", "7", "9"])); "extracts word digit to digit with prefix and overlapping word digits")]
 fn test_parse_digits(input: &str, want: IResult<&str, Vec<&str>>) {
 assert_eq!(parse_digits(input), want);
 }

Note the last test case above, which is me thinking my genius has realised the trick here: sevenine will need to be parsed as vec!["7", "9"]. Being very self-satisfied at noticing this, I scanned the other words and didn’t immediately see any other exceptions like this and continued on. This cost me time and frustration later when I couldn’t get the correct result for my actual input, even though it worked for the example input. Lesson for me to re-learn? When you find an exception, always check all permutations explicitly for other exceptions, or even better, find a generalisation that removes the need for exceptions. As it turns out, I missed the following additional test-cases initially:

 #[test_case("oneight", Ok(("", vec!["1", "8"])); "extracts overlapping word digit oneight")]
 #[test_case("threeight", Ok(("", vec!["3", "8"])); "extracts overlapping word digit threeight")]
 #[test_case("fiveight", Ok(("", vec!["5", "8"])); "extracts overlapping word digit fiveight")]
 #[test_case("nineight", Ok(("", vec!["9", "8"])); "extracts overlapping word digit nineight")]
 #[test_case("eightwo", Ok(("", vec!["8", "2"])); "extracts overlapping word digit eightwo")]
 #[test_case("eighthree", Ok(("", vec!["8", "3"])); "extracts overlapping word digit eighthree")]

Part 2 Step 1: parsing words as well as digits

I added a small function to alternately parse either a word digit or a numerical digit:

fn parse_word_or_num_digit(input: &str) -> IResult<&str, Vec<&str>> {
 alt((parse_word_digit, map(digit1, |d| vec![d])))(input)
}

Note that this function (and the one below) needs to return a Vec<&str> rather than just a single &str because input such as sevenine results in two numbers being returned by parse_word_digit (though I could have also chosen to return "79" I guess).

The actual implementation of parse_word_digit is then pattern matching for quite a few alternatives (updated to include the extra alternatives I’d missed originally):

// Note that certain words can overlap, the only one I can see is:
// sevenine (correction - there are quite a few, see below).
// LEARN: avoid confirmation bias - finding one exception and thinking that's the
// missing piece, rather than looking exhaustively for all exceptions.
fn parse_word_digit(input: &str) -> IResult<&str, Vec<&str>> {
 map(
 alt((
 tag("oneight"),
 tag("one"),
 tag("twone"),
 tag("two"),
 tag("threeight"),
 tag("three"),
 tag("four"),
 tag("fiveight"),
 tag("five"),
 tag("six"),
 tag("sevenine"),
 tag("seven"),
 tag("eightwo"),
 tag("eighthree"),
 tag("eight"),
 tag("nineight"),
 tag("nine"),
 )),
 |word| match word {
 "oneight" => vec!["1", "8"],
 "one" => vec!["1"],
 "twone" => vec!["2", "1"],
 "two" => vec!["2"],
 "threeight" => vec!["3", "8"],
 "three" => vec!["3"],
 "four" => vec!["4"],
 "fiveight" => vec!["5", "8"],
 "five" => vec!["5"],
 "six" => vec!["6"],
 "sevenine" => vec!["7", "9"],
 "seven" => vec!["7"],
 "eighthree" => vec!["8", "3"],
 "eightwo" => vec!["8", "2"],
 "eight" => vec!["8"],
 "nineight" => vec!["9", "8"],
 "nine" => vec!["9"],
 _ => panic!("non digit word"),
 },
 )(input)
}

Part 2 Step 2: Checking for digits one char at a time…

This step introduced me to a new nom function that I needed: many_till which will continue consuming from the input (using the first provided argument) until the second provided argument is able to parse something. For this problem, I’m simply consuming a single character until I’m able to parse a word or number digit:

// parse_digits takes one charachter at a time from the input until
// it is able to parse a word or number digit, ignores the characters that
// weren't part of a word or digit, and returns a single flattened Vec<&str> of
// the result.
fn parse_digits(input: &str) -> IResult<&str, Vec<&str>> {
 let (rest, digit_vecs) = many1(map(
 many_till(take(1u8), parse_word_or_num_digit),
 |(_, word_or_num)| word_or_num,
 ))(input)?;
 Ok((rest, digit_vecs.into_iter().flatten().collect()))
}

Note that we need to flatten the returned vector (that is, it’s a vector of vectors of calibrations and we want to flatten that result to a simple vector of calibrations) only because parse_word_or_num_digit itself returns a vec of calibrations (for the exception cases of sevenine etc).

With that we can then write a small parse_calibration_part2 function that calls parse_digits and maps the result through first_n_last to get the first and last digits the same as in part 1:

pub fn parse_calibration_part2(input: &str) -> IResult<&str, u32> {
 map(parse_digits, |digits: Vec<&str>| first_n_last(digits))(input)
}

Aaaand with that, tests pass again and my part2 binary (virtually the same as the part1 one at the beginning) gives the correct answer.

What did I learn here?

So the main point that caused issues for me in this exercise was confirmation bias when I found what I thought was the (single) trick of overlapping word-digits (sevenine) and checked too casually for other similar overlapping words, rather than exhaustively checking through the ten options. I need to reinforce that when I discover an interesting or unexpected case, that I exhaustively check for other instances of the same.

And I got to use a new nom function, many_till which will be incredibly helpful for other parsing situations here in the advent of code, I’m sure.