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?

[LPTK]

@He-Pin I don't know what's the current status of this problem. I no longer use fastparse myself. The code in this PR was written on 2018 and never reviewed by @lihaoyi.

[He-Pin]

@LPTK I think that's because there well need a Scala 3 part too now ? thanks for the update.

[LPTK]

Would be nice if there was a check there as well I guess (haven't tried the Scala 3 version), but that shouldn't be a requirement for adding the Scala 2 check in this PR.