Spanned arguments

[audunhalland]

This change improves diagnostics when performing manual/domain-specific post-validation of arguments using LookAheadArguments. In the case of an error, the produced error message may be able to refer to the exact position in the problematic GraphQL arguments.

I figure this breaking change can be seriously considered, as Juniper looks set for a breaking release anyway.

[audunhalland]

A change that could be done to improve this is to somehow borrow the (start, end) tuple in LookAheadArguments instead of copying it. But the problem is that start and end are two independent fields of Spanning<T>, and those two fields can't be borrowed together without also borrowing the item: T, resulting in a leaky abstraction.

Edit: I propose a redesigned Spanning like this:

struct Spanning<T> {
    pub item: T,
    pub span: Span
}

struct Span {
    pub start: SourcePosition,
    pub end: SourcePosition,
}

[tyranron]

@audunhalland could you provide some meaningful examples where do you want this?

[tyranron]

@audunhalland could you provide some meaningful examples where do you want this?

Giving it a little bit more thoughts, I now better understand how this may be useful, and overall okay with this course of changes.

Edit: I propose a redesigned Spanning like this:

struct Spanning<T> {
    pub item: T,
    pub span: Span
}

struct Span {
    pub start: SourcePosition,
    pub end: SourcePosition,
}

Yup, that would be better.

[audunhalland]

@tyranron thank you for the review! I think the Spanning redesign should be a separate PR and I'll instead rebase this one.

[audunhalland]

That PR is up at #1207

[audunhalland]

I'll close this PR and open a new one on top of #1208 later.