Check that parameters used in parsers are by-name (or of wildcard type)

[LPTK]

The right way of doing parameterized parsers is to use by-name parameters, as in:

def twice[T, _: P](p: => P[T]): P[(T,T)] = p ~ p

However, currently nothing prevents users from not using a by-name parameter. And nothing in the API seems to imply that parser parameters should be by-name.

I made the mistake myself, and was bitten by a class-cast exception coming out of nowhere. If you're lucky, you'll get a strange warning saying "a pure expression does nothing in statement position" which hints at a problem – but you won't necessarily get that warning, and it's not sufficient for users to know how to solve the problem anyway.

This PR augments the fastparse macros with a checking pass that makes sure the parsers that come from parameters are from by-name parameters.

It's not a complete check by any means and can be subverted, but I think it's much better than nothing.

[LPTK]

Hey @lihaoyi. Thoughts about moving forward with this?

[lihaoyi]

@LPTK haven't had time to properly review it yet; do you mind if I just leave this here for a while?

[LPTK]

Not at all, no worries 😉

[andyczerwonka]

@LPTK haven't had time to properly review it yet; do you mind if I just leave this here for a while?

This sounds like the same issue I've reported on the Gitter channel.

@lihaoyi is there no way to pass a collection of strings into the parser?

[milanvdm]

@lihaoyi Any progress on this?
Ive got the exact same issue that @andyczerwonka is describing: StringIn(listOfStrings:_*) fails with Function can only accept constant singleton type

[He-Pin]

@LPTK Any update?