Here's what I see:

$ cargo build --bin ex04
error: no bin target named `ex04`.
Available bin targets:
    exercise
    exercise_08
    soln08
    solutions_08

For some reason, the Rustlings lifetime link has been updated with a new section. I have just started going through the book and realised the old link is broken, the new link should be https://github.com/rust-lang/rustlings/tree/main/exercises/16_lifetimes.

Edit: Noticed a PR has been opened for this. thanks #28

Pointed out by @ctm

Will do as soon as we don't have PRs that'll cause a merge conflict.

https://github.com/tfpk/lifetimekata/blob/main/exercises/07_special_lifetimes/TODO_EXERCISES is really a strange empty file
I suggest to remove it, convert to an issue, or fill with couple of meaningful words

As suggested by @ctm :

I think lifetimekata would benefit from a chapter on HRTBs
I've had to use them every once in a while, but when I do so, it involves a bunch of trial and error and/or web searching.

Can we improve task definition so that limitations would be obvious from the start? It's my bad, I wasn't reading thorough enough, but staring long enough at Matcher::new signature output I decided that there's no way it could return None. Implemented it the way unmatched parenthesis go to RawText(_), and of course smashed into broken_matcher() test.

It's just a piece of feedback... Do you feel like that this detail deserve few words in the chapter?

In chapter 4, the first part of the exercise asks the reader to explain why an error occurs, however there is no solution to this part of the exercise. Therefore the reader may be unsure whether their answer is correct. This can be remedied by either adding a click-and-reveal solution/answer, or including the answer in the solutions subdirectory

Towards the end of the first chapter, once the 'variable and 'reference lifetimes has been established, there is the following statement:

We call a region of code where a variable exists a "lifetime". We can give lifetimes names using the syntax 'name. So if we call the variable's lifetime 'variable, and the reference's lifetime 'reference, we can then formally say that for any variable that references another variable, 'variable must be larger than 'reference.

The last part of this statement is confusing to me because it does not seem to be true for all cases.

Let's say in the code example, that the inner scope of 'variable is expanded to include the if let statement:

fn main() {
    let mut my_reference: Option<&i32> = None;

    // Starting a scope.
    {
        // my_variable created                               // \ \
        let my_variable: i32 = 7;                            // | |
        my_reference = Some(&my_variable);                   // | |- my_variable exists here. ('variable)
        // At the end of the scope, `my_variable` is dropped // | |
        drop(my_variable);                                   // | |
        // my variable destroyed                             // | /
    // inner scope does not stop here }
                                                             // |
    if let Some(reference) = my_reference {                  // |
        println!("{}", reference);                           // |
    }                                                        // /
    } // inner scope now stops here
}

It is not true that 'variable is now larger than 'reference, because 'reference is declared earlier still.

So this is confusing to me. It would make more sense if it read:

we can then formally say that for any variable that references another variable, 'variable must live longer than 'reference.