Prepend super:: to function calls

[jhpratt]

Resolves #173. See that issue for details.

If I have missed anything, let me know!

[la10736]

Ok... is not so simple.... Lot of tests fail 😢 . Unfortunately not every cases are rendered in a module...

i.e.

#[rstest]
fn simple() {
}

So we should handle the two behaviors. Moreover there is a case that maybe we cannot solve:

#[fixture]
fn other() -> u32 {
    42
}

#[rstest]
fn hard(#[from(other)] hard: u32) {
}

I don't think there is a way to solve it without introducing a new indirection that I would avoid to not complicate the backtrace... we cannot know the absolute path while the procedural macro run.... But we can ignore this corner case... I guess

Beside that, can you add E2E tests too?

We should test both plain to check that doesn't brake anything, use #[values(...)] and use #[case] .... fixture when we have also case should works in the only interesting case: when we use #[from] annotation because otherwise that meas we have fixture and test function with the same name.

Example for fixture case:

#[fixture]
fn fortytwo() -> u32 {
    42
}

#[rstest]
#[case(2)]
fn value(#[from(fortytwo)] value: u32, #[case] v: u32) {
    assert_eq!(v, value*v/42); 
}

[jhpratt]

Ok... is not so simple.... Lot of tests fail 😢 . Unfortunately not every cases are rendered in a module...

I should have known better than to only check my specific crate and to run the actual tests.

I don't think there is a way to solve it without introducing a new indirection that I would avoid to not complicate the backtrace... we cannot know the absolute path while the procedural macro run.

Now that you say this, I have worked around it in the past (iirc) with a bit of indirection that you mention. It may or may not be applicable here, but it's totally fine if you don't want to do that.

This (still) isn't a top priority for me, but I'll probably get to it in the near-ish future. It depends how bored I get on some arbitrary night, most likely 😅