tryCompiletimeConstantFold in disjointnessBoundary

[EugeneFlesselle]

Fixes #20166

Alternatively placing the tryCompiletimeConstantFold in AppliedType#superType also seems to fix the issue and not break anything. But I'm not very sure about the spec here either way.

@sjrd

[soronpo]

I believe this requires a spec change. Maybe @smarter can address this in scala/improvement-proposals#84

[soronpo]

But I'm not entirely sure #20166 requires a fix.

[EugeneFlesselle]

But I'm not entirely sure #20166 requires a fix.

If not the match types, then the compiletime.ops documentation needs to be modified. Right now they are contradictory.

scala3/library/src/scala/compiletime/ops/int.scala

Lines 5 to 21 in 62e0641

	/** Successor of a natural number where zero is the type 0 and successors are reduced as if the definition was:
	*
	* ```scala
	* //{
	* import compiletime.ops.int.*
	* //}
	* type S[N <: Int] <: Int = N match {
	* case 0 => 1
	* case 1 => 2
	* case 2 => 3
	* // ...
	* case 2147483646 => 2147483647
	* }
	* ```
	* @syntax markdown
	*/
	type S[N <: Int] <: Int

[soronpo]

I don't understand, where is the contradiction? Where does it state that compiletime.ops can generally appear in a match type case? S is special cased in the match-type spec. It has known properties that define the disjointness well. It's not true for all the compiletime.ops operators.

[EugeneFlesselle]

I don't understand, where is the contradiction? Where does it state that compiletime.ops can generally appear in a match type case? S is special cased in the match-type spec. It has known properties that define the disjointness well. It's not true for all the compiletime.ops operators.

We observe different semantics when replacing usages of compiletime.ops.int.S by what the documentation sais it is equivalent too (the test has an example). Independently of where it is used, I would say that is a contradiction.

[EugeneFlesselle]

I've dropped aaf2dc7 from this PR in favour of having it in #20257.

[sjrd]

Sorry for dropping this.

AFAICT, this is correct. When we fall in that case, it should be the case that tp =:= tp.tryCompiletimeConstantFold, so they should agree on being provably disjoint or not.