before:

scala 2.13.0-M5> 3 toString()
res4: String = 3

after:

scala> 3 toString()
         ^
       error: no arguments allowed for nullary method toString: ()String

because it's being taken as if I'd written:

scala> 3.toString(())
                  ^
       error: no arguments allowed for nullary method toString: ()String

this doesn't seem to match what you wrote above, namely "x op() is corrected to x.op()"?

discovered because it broke ScalaTest in the 2.13 community build. I had to:

-        outputStream getChannel() transferFrom(Channels.newChannel(inputStream), 0, Long.MaxValue)
+        outputStream.getChannel().transferFrom(Channels.newChannel(inputStream), 0, Long.MaxValue)

not sure how widespread breakage is.

@SethTisue sorry, what I meant was, "I corrected the spots in the compiler where they wrote x op()."

I noticed it here: #6974 (comment)

I think the bad syntax hearkens back to the loose days when folks decided that dots were optional everywhere, the way they once started saying that braces and parens are interchangeable.

Edit: also that parens are optional everywhere, like clothing. What decadent times!

@SethTisue I rediscovered how to look at the community build runs; it's a bit hard to just find the first error; if I see that something isn't building, is the protocol to PR upstream or do something so the CB project can try it out?

Edit: I see that there are local projects I could PR to.

@som-snytt it's okay, I'm on it, usually it's easiest for me to just do the needed tweaks myself. for others to try to navigate community build stuff is usually an unnecessary time sink for them. in cases where I need help, I'll ask for it :-)

in this case I dealt with ScalaTest via scalacommunitybuild/scalatest@81302db , I'm currently seeing how much other breakage there is, but I have several other 2.13.x breakages (unrelated to this PR) I also need to address at the same time... I'll come back here once the dust has settled somewhat.

I won't bug you about it now. I thought I was running a local build just for utest, but I guess it's doing the full suite. I had exercised dbuild once before and fixed something somewhere, so I know it's possible. Probably I was in better shape back then.

but I guess it's doing the full suite

it extracts dependencies for everything even if you are only actually building a subset, could be what you're seeing. and for the first run, extract dependencies from 180 repositories takes a looooong time (after that the results are cached, unless you change the Scala SHA or something else fundamental).

usual workaround if you are working on something at least somewhat near the root (like utest or cats) is to delete everything in community.dbuild below the project you care about. (I do my best to keep the file ordered in such a way that this works.)

so far it's looking like breakage is not that common 👍

@som-snytt would you mind updating the PR description to include a bit of motivation, aimed at end users who are seeing the change and wondering what the story is? (example: scala/bug#11475)

@SethTisue maybe also promote the message improvement to RC2 scala/bug#11461

@som-snytt new description is better, thanks.

re 11461, I think a fix would be accepted for RC2, but I'd prefer not to put any non-blocker bugs on the milestone

I've improved the title as well. (in dem Release-Notes auch)