-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Regression in typer for named arguments of infix methods in ghostdogpr/caliban
#21767
Comments
cc @odersky |
No, it should not. Argument syntax should be tied to regular method calls, An infix operator takes two expressions; there is no argument list in the traditional sense. Another case where this matters is a *: (b, c) This should really preprend Workaround: val fails = field.toGraphQL(queryName = Some("GetCharacter")) It's a lot clearer anyway. As with the other named tuple problem we should try to do a migration warning and offer a rewrite rule. |
I agree that this code was weird, I fixed it in Caliban: ghostdogpr/caliban#2440 |
Previous attempt giving warning: #21565 |
Based on OpenCB failure for
ghostdogpr/caliban
- build logsAffects also:
openmole/container
- build-logsscala-stm/scala-stm
- build logsshopstic/caliban
(fork of project above) - build logstarao/record4s
- builds logstpolecat/atto
- build logsalgolia/algoliasearch-client-scala
- build logsThe new behaviour might have become present by the stabilization of named tuples. Previously named tuples syntax was not tried without an explicit experimental flag enabled.
Compiler version
Last good release: 3.6.0-RC1-bin-20241003-a672e05-NIGHTLY
First bad release: 3.6.0-RC1-bin-20241005-6fa81cf-NIGHTLY
Bisect points to 87cdbc8
Minimized code
Output
Expectation
The compiler should interpret infix apply as list of arguments instead of named tuple.
The text was updated successfully, but these errors were encountered: