Accept and ignore using in method calls (to aid cross-building with Scala 3)

[som-snytt]

Users using using on Scala 3 may use using on Scala 2 in arguments to method invocations, for purposes of cross-compilation. The using keyword is ignored and not used in that context under Scala 2.

references scala/scala3#15552

[som-snytt]

using ought to be the hit internet karaoke platform. Get it? "you sing"! Where do I cash in my chips?

[lrytz]

g(using using) works too 😀

[som-snytt]

I wish I had thought of that one. Maybe I'll add another test class MaliciousPuns.

[lrytz]

@SethTisue this could go in 2.13.9 I think.

[som-snytt]

Added the devilish test as suggested, and rebased and squashed.

[smarter]

Would you mind opening issues against https://github.com/scalameta/scalameta/issues/ and https://youtrack.jetbrains.com/issues/SCL#newissue to let them know that they need to be update their respective parser for 2.13.9?

[smarter]

Also I'd vote for backporting this to 2.12.

[SethTisue]

2.12 backport merged: #10075

[SethTisue]

Would you mind opening issues against https://github.com/scalameta/scalameta/issues/ and youtrack.jetbrains.com/issues/SCL#newissue to let them know that they need to be update their respective parser for 2.13.9?

The status quo on this is that we use the "release-notes" label to indicate PRs which are compatibility concerns for tooling authors. The label also goes on other sorts of PRs, but the number of PRs with the label isn't that large and thus shouldn't be unwieldy for tooling maintainers to review.

We also use https://contributors.scala-lang.org to announce progress on upcoming releases, and we recently lengthened the span of time (now two weeks) between announcing a release candidate and actually releasing, to give tooling authors more time to adapt to recent changes such as these.

The matter is open to further discussion (on https://contributors.scala-lang.org, please, rather than on this particular PR), but I want to state clearly that the current model is that we expect tooling authors to monitor what's coming from upstream — and we're doing our best to make it reasonably convenient for them to do so. We don't expect our contributors (and ourselves) to notify individual tooling projects of individual changes.

[smarter]

I don't know about what should happen in theory, but in practice I've had great success being proactive (https://github.com/scalameta/scalameta/issues?q=is%3Aissue+is%3Aclosed+author%3Asmarter+, https://youtrack.jetbrains.com/issues?q=by:%20smarter%20), whereas here it seems that IntelliJ isn't aware of the change from this PR even though 2.13.9 is about to be released.

Related discussion: https://github.com/scala/improvement-proposals-discussions/discussions/12