cargo-aoc
cargo-aoc copied to clipboard
Cannot use lifetimes in return types for `aoc{,_generator}`
When one uses a return value with a lifetime in it, #[aoc(...)]
panicks with an error similar to:
~/…/personal/advent-of-code-2018 lifetime-problems$ cargo build
Compiling advent-of-code-2018 v0.1.0 (<snip>)
error[E0261]: use of undeclared lifetime name `'a`
--> src\day6.rs:47:1
|
47 | #[aoc(day6, part1)]
| ^^^^^^^^^^^^^^^^^^^ undeclared lifetime
error: aborting due to previous error
For more information about this error, try `rustc --explain E0261`.
error: Could not compile `advent-of-code-2018`.
To learn more, run the command again with --verbose.
You can check out a fully-reproducible example that the above is based on in the lifetime-problems
branch of my AoC2018 solutions. The most interesting file is day6.rs
, which I'll inline for posterity since I'll be deleting that branch once this issue is resolved:
use {
aoc_runner_derive::{
aoc,
aoc_generator,
},
re_parse::{
Regex,
ReParse,
},
serde_derive::Deserialize,
std::str::Split,
};
#[derive(Debug, Deserialize, ReParse)]
#[re_parse(regex = r#"(?P<x>\d{1,10}), (?P<y>\d{1,10})"#)]
struct Coordinate {
x: u32,
y: u32,
}
#[derive(Debug)]
struct CoordinateParser<'a> {
input: Split<'a, char>,
}
impl<'a> CoordinateParser<'a> {
pub fn new(input: Split<'a, char>) -> Self {
Self {
input,
}
}
}
impl Iterator for CoordinateParser<'_> {
type Item = Coordinate;
fn next(&mut self) -> Option<Self::Item> {
Some(self.input.next()?.parse().unwrap())
}
}
#[aoc_generator(day6)]
fn day6_generator<'a>(input: &'a str) -> CoordinateParser<'a> {
CoordinateParser::new(input.trim().split('\n'))
}
#[aoc(day6, part1)]
pub fn day6_part1(input: CoordinateParser<'_>) -> u32 {
println!("input: {:#?}", input);
0
}
I'm a beginner in rust and I don't feel I'd be able to fix this issue. Is there a recommended workaround? Circumventing the need for a lifetime I expect?
I have no idea how to resolve a similar-looking error. main()
it is, then.
It does not work with impl Trait
as return time either.
From what I understand it is because the return type of the generator is used to define a field in the RunnerStruct
.
I came across this limitation recently and I opted to simply not use a generator in my solution. This meant simply calling my parsing function from within my solution function.