Set default source version to 3.5

[hamzaremmal]

Superseeds #20435
Closes #20415

[test_scala2_library_tasty]
[test_windows_full]
[test_java8]

[hamzaremmal]

How I fixed it

First, I've changed the default source version from 3.4 to 3.5. This change will trigger a number of uses in scala2-library-bootsrapped and scala2-library-cc. I've then cloned the source code of the scala2 library using the following commands in sbt: scala2-library-cc/run overwrite <path> and scala2-library-bootstrapped/run overwrite <path> (eg: scala2-library-cc/run overwrite scala/Array.scala). After cloning the missing files, I've proceeded with the changes to adapt the library to Scala 3.5

[hamzaremmal]

@Kordyjan This PR will need to be backported to the 3.5 release branch and be included in 3.5.0-RC2

[odersky]

@hamzaremmal I added you to dotty-staging/dotty. So in the future you can push your PRs there or add commits to existing PRs.

[hamzaremmal]

@odersky Should be good for review now. @natsukagami can you take a look at why semanticdb somtimes include the diagnostics and sometimes it doesn't (should not block this PR since I commented it for now)

[natsukagami]

We are emitting the following warning inside the semanticdb test

-- Warning: tests/semanticdb/expect/InventedNames.scala:35:20 ------------------
35 |val c = given_Double
   |                    ^
   |Given search preference for Int between alternatives (givens.intValue : Int) and (givens.given_Char : Char) will change
   |Current choice           : the second alternative
   |New choice from Scala 3.6: the first alternative

... but not always, this seems to be because of the usage of the -usejavacp flag. When used within sbt and with the bootstrapped compiler, my guess is that a bunch of new classpaths are passed into the compiler as javaUserClassPaths, some of them from sbt. This changes the order of the implicits that are found (between char and int...) in searchImplicit.

From the ordering used inside searchImplicit (see compareEligibles, Implicits.scala:1500) these two instances do not differ, so we end up with different ordering of the candidates depending on the order they were found (from elsewhere, I haven't figured out exactly where).

Further up we can see rank uses compareAlternatives (where the warning was introduced) to preemptively remove future worse candidates once it has found one success

scala3/compiler/src/dotty/tools/dotc/typer/Implicits.scala

Lines 1431 to 1436 in 7bdeb0b

	case retained: SearchSuccess =>
	val newPending =
	if (retained eq found) || remaining.isEmpty then remaining
	else remaining.filterConserve(cand =>
	compareAlternatives(retained, cand) <= 0)
	rank(newPending, retained, rfailures)

Here note that with two candidates given_Char and intValue, given_Char will always fail tryImplicit and the other will succeed.
However,

• If given_Char comes before intValue in the candidate list, it gets eliminated immediately, and no warnings are thrown
• If intValue comes before, then tryImplicit succeeds, and rank tries to preemptively compare intValue to the (to be failing anyway) given_Char candidate. This produces the warning.

I can see a few things to do here:

• Enforce a stricter ordering of candidates so that it's more deterministic
• Perhaps try to somehow not produce the warning when tryImplicit would fail anyway, since it's confusing to the user

[odersky]

@natsukagami That's a great analysis. Let me see if we can somehow delay the warning to the point where we choose one of the implicits that are mentioned in it.

[odersky]

See #20480 for a fix that should suppress the spurious warnings.

[odersky]

We should remember to re-enable the semanticdb diagnostics when #20480 is merged.

[hamzaremmal]

We should remember to re-enable the semanticdb diagnostics when #20480 is merged.

Indeed, I suggested to do it in the same PR since it was the trigger for this change