Scala 3.2.0 reveals "non-local return' defects

[LeeTibbert]

This is a placeholder. Something to peck away at whist waiting for CI jobs to complete.
Later: Scala 3.0 deprecated non-local returns (see Scala 3.0 docs) and announced that
they would be removed in some future release. Scala 3.2 is now more vocal about
letting people know that they are deprecated. Time passes, Life evolves.

So, yes, these are real.

Building SN itself with Scala 3.1.3 brought with it a set of warnings. I have
been meaning to take a run at them, but like black flies in June in Maine,
one gradually gets used to them.

Building with the new Scala 3.2.0 seems to have brought a rash
of new warnings.

[warn] -- Warning: /mnt/AthaBHdd1/lee49/DevoHdd1/scala_native/WorkSpace_1/2022/study_SN_Scala320_build_2022-08-31T1343-0400/javalib/src/main/scala/java/net/SocketHelpers.scala:174:8 
[warn] 174 |        return scala.Array.empty[String]
[warn]     |        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[warn]     |Non local returns are no longer supported; use scala.util.control.NonLocalReturns instead

These are in javalib and not deep into the SN compiler so they look accessible. There are a bunch all of
the same type, so the same fix could be rolled out over a number of places.

The hard part is if the recommended fix scala.util.control.NonLocalReturns is available as far back
as Scala 2.11. Probably far easier to just restructure the code.

[WojciechMazur]

I agree that restructuring the code would be the best solution right now. NonLocalReturns are deprecated in 3.2.0, but it's not yet agreed when this feature would be removed, probably in Scala 3.3 or 3.4, so probably in a span of 6-18 months.

The recommended fix is available only for Scala 3 - scala.util.control.NonLocalReturns is not available in Scala 2. However, Scala 2 uses internally the same mechanism using controlled exception handling. (using `scala.runtime.NonLocalReturnControl). One solution would involve creating a wrapper or a Scala2 only implementation of mentioned methods that can be used for both Scala2 and Scala3.

SN artifacts currently would be published using Scala 3.1.3 and that probably would not change until the first release of Scala LTS.

[LeeTibbert]

@WojciechMazur Thank you for the timely and helpful response.

Whilst waiting for CI jobs to complete, I took the time to read up on 3.2.0
now giving a more direct warning about the Scala 3.0 deprecation of
Non-local returns.

Reading how they are implemented, I can understand why that deprecation
was done. Always hard taking things away from people. I think most
programmers with an assembly knowledge background thing of ret
return instructions as not free but trivially cheap. Not here.

Some people, not me, actually like and advocate the "return early, return often"
style of programming. Within the past two or three months I have seen not
one but two programming style guide from major corporations recommending/
requiring that.

Much as I dislike disturbing the slumber of code which is not exhibiting
problems, I think that restructuring as first choice is the way to proceed,
with using the new NonLocalReturnControl as last resort.

A number of the new 'non-local' are in java.net. I removed a few
(and avoided introducing another few from following existing practice)
in my IPv6 PR. I can peck away at InetAddress and kin.

I think it is possible to use SN's access to system C libraries to remove
and simplify a massive amount of code in that area. The need to
get rid of 'non-local return' may give me both motivation & cover for
doing that. I have held of under the "do not disturb the sleeping baby'
rubric. Now the baby is crying.

[LeeTibbert]

@WojciechMazur Is OK with you if I do these corrections in the 0.5.0 stream or would it be easier for you
to merge in the 0.4.x stream (or "do something, timely, and I will figure it out as needed").

So much of my recent work has been on breaking changes that my thoughts naturally go first to 0.5.0.
In theory, these should not be breaking (if I get out cleanly). However, when I am moving large chunks
of code around I always like to give them some time for introduced defects to become apparent through
use. Your call. Not urgent.

[WojciechMazur]

Sure, it can be fixed in the 0.5.0 first, then we can backport it to the 0.4.x

[LeeTibbert]

Thank you. That gets me moving. This is a background task, so progress may be slow.

[LeeTibbert]

Asking before I leap:

Is it OK to use import scala.util.control.NonLocalReturns.* and associated language
constructs in javalib?

Scala.js did a sweep through their javalib to eliminate dependencies on Scala libraries.
For historical reasons, such dependencies are all over the place in Scala Native javalib.
There has been an attempt over the past few years to at least not introduce new such
dependencies.

I ask because even though Scala 3 NonLocalReturn looks like a language feature,
it might be implemented in a way which depends upon Scala libraries. Those Collections
and such are just so useful (and Java itself is so limited).

Thank you.

I got all of one line into fixing java.math.Primality before encountering this question.
I am having to write missing tests before I can even begin restructuring code.

cc: @ekrich Eric, this is FYI, since you have been the motivating advocate for ScalaOps, etc.

[LeeTibbert]

To co-ordinate efforts and, hopefully, eliminate wasted work...

I am in the process of making extensive changes to javalib InetAddress*.scala and SocketHelpers.scala
for other reasons. A welcome byproduct of this work is that it should eliminate 30 or more non-local return
warnings.

[LeeTibbert]

I am in the process of removing 20 or 30 'non-local return' warnings in javalib InetAddress.scala and friends,
well, mostly the friends.

I got tired of looking at the 'non-local return' warnings from other files. They made it hard for me
to tell if the files I was working on for other reasons had warnings. So I took a run at
removing them.

I hit the end of my leash pretty quickly. I want to document for others, including
myself in a few days time, what caused progress to halt.

I removed the warnings in StringTokenizer.scala and submitted a PR.

Primality.scala and URI.scala need either someone with more patience,
time, and energy that I, or the documented Big Hammer: import scala.util.control.NonLocalReturns.*

That is supposed to exist in Scala 3.2.0 and above.
It looks like the SN scala library is currently being built against Scala 3.1.3. I think I remember
that there was a reason why that is necessary at present.

So, my non-local return work in javalib is paused, as might similar work
in other sub-projects which require NonLocalReturns.

Other projects might have files which could be re-written to avoid
'returns`. Such a re-write is preferable, if it can be done in
economic time.

[LeeTibbert]

The merged PR was a partial fix, I believe there a large number of non-local return errors remaining.
I know of at least 20 (down from 50+ ) that happen to me each time I run tests on the javalib changes
I have in development.

[ekrich]

Looks like Primality has removed non-local-returns in JS so maybe that is an easy get - URI could probably be re-ported as well - I could do those if needed.

[LeeTibbert]

I had not seen that in Scala.js. I had thought I had looked there.
I do not want to sideline your promising & productive SN build work,
I could take a run at this. If only to the point of evaluating the
Scala.js solution.

scala.util.control.NonLocalReturns is not available before Scala 2.13.mumble, I think.

I was going to take a trial run at this, using the existing directories in javalib/src/main.

resources/
scala/
scala-2/
scala-2.11/
scala-2.12/
scala-2.13/
scala-3/

[LeeTibbert]

I've ignored this one for months, saying bad words each time I ran my test. I've run
out of bad words to say.

[LeeTibbert]

Scala.js Primality.scala ports to SN 3.2.0 with only three(?) minor changes (missing ()).
Now to see if it passes tests (or if tests exist). The to see if SN 2.11.mumble likes it.

Spoke/wrote too early, do-while does not exist in SN 3.n. More hacking needed
in 2 or 3 places.

[ekrich]

Some stuff of course we can't port and I also port the tests into the new location. I noticed in Primality they removed for where they had return otherwise for is ok and still there. Other than that, nothing else. That is what I recommend as well - had many in sconfig that I fixed early on in the Scala 3 process.

I think if there is a newer version in Scala.js, that is the ticket. If we have any in collections those porting efforts are harder.

Wow, so they have do-while - that is weird.

Edit: at least only one place - I think there focus was to free the Java lib so it perhaps happened earlier - That means you have to port it back?

[LeeTibbert]

I have this ready to submit If that is OK by you. I would appreciate your checking the
changes. The reward is that you get to give me a bit of grief about using a var ;-) or
whatever non-passive-aggressive emoticon is allowed these days.

No test that I could fine in SN. While it is going thru CI, I may check Scala.js.

Sound like a plan, or do you have something ready to go? If the latter, I will stand down
if favor of that.

Any quick thoughts about URI. I could check Scala.js again.

[LeeTibbert]

I have run out of steam. Just to let others know what I have found on URI.scala

TL;DR; A robust fix requires the posixlib pton (presentation to network) call. Let C figure out
the parsing. To avoid introducing a posixlib dependency, I think I can hack the code so that
it will run on SN 3.n & 2.n on the same source. It will not be pretty or classroom demonstration
text, but it may be done and no longer kicking me/us whilst trying to get useful work done.

Longer story.

1. Avoiding regex, runtime pig, even on never executed code.
2. Nothing obviously portable from Scala.js in economic time.
3. nothing obviously worth porting from Java to SN in Android Harmony luni.

My working goal is to not get rid of every eyesore return but only
the ones Scala 3.2.n is complaining about. I have work in other areas
of SN which will bring more benefit to the project.