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 😅

[jhpratt]

@la10736 Random thought as I encounter this again…wouldn't it be simplest to change a call to foo into __rstest_foo? While not foolproof, I'd have to blame someone who writes an argument with that name if the situation ever arose. The module and test name would remain the same, so test output wouldn't change.

[la10736]

Ok, I've some toughs about it. Maybe I'll end to handle in a different way the two cases.