Skip to content

Conversation

@EugeneFlesselle
Copy link
Contributor

@EugeneFlesselle EugeneFlesselle commented Sep 14, 2025

Reverts #23920

@EugeneFlesselle EugeneFlesselle force-pushed the distributeAnd-revert-revert branch from a5ec473 to 4d2442b Compare September 14, 2025 15:46
@EugeneFlesselle
Copy link
Contributor Author

@hamzaremmal all ci-checks (including scala-library-bootstrapped) pass (but so did they in the original PR). How do we test the same issue does not occur?

@hamzaremmal hamzaremmal marked this pull request as ready for review September 15, 2025 11:57
@hamzaremmal hamzaremmal requested a review from a team as a code owner September 15, 2025 11:57
+CC[X] <: SortedSet[X] with SortedSetOps[X, CC, CC[X]],
+WithFilterCC[x] <: IterableOps[x, WithFilterCC, WithFilterCC[x]] with Set[x]] extends SortedSetOps[A @uncheckedVariance, CC, CC[A @uncheckedVariance]] {
self: IterableOps[A, WithFilterCC, _] =>
self: IterableOps[A, WithFilterCC, CC[A @uncheckedVariance]] =>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked both changes here with @sjrd and they should be fine.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reverted the PR as I had doubt over this change and it was breaking everything.

Copy link
Member

@sjrd sjrd Sep 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now I'm getting the following, but in unclear situations (clean build worked; recompiled with a clean scala3-libary-nonbootstrapped does not work).

[error] -- [E046] Cyclic Error: /localhome/doeraene/projects/dotty/library/src/scala/collection/Iterable.scala:992:11 
[error] 992 |    +CC[X] <: SortedSet[X] with SortedSetOps[X, CC, CC[X]],
[error]     |           ^
[error]     |           Cyclic reference involving trait SortedSet
[error]     |
[error]     |            Run with -explain-cyclic for more details.s
[error]     |
[error]     | longer explanation available when compiling with `-explain`

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hum, no, cleaning the library project fixes it. But still, it means it's appearing under some separate/incremental compilation scenarios. :s

@hamzaremmal
Copy link
Member

hamzaremmal commented Sep 15, 2025

How do we test the same issue does not occur?

It was a bad interaction with the build cache. I went ahead and completely disable it in the meantime.

@hamzaremmal hamzaremmal merged commit c8d77df into scala:main Sep 15, 2025
43 checks passed
@hamzaremmal hamzaremmal deleted the distributeAnd-revert-revert branch September 15, 2025 11:59
@WojciechMazur WojciechMazur added this to the 3.8.0 milestone Oct 28, 2025
odersky added a commit that referenced this pull request Nov 2, 2025
#24175)

Fixes #24038

In the minimisation, the typer phase expanded
```scala
case abcd: (h *: t, bh *: bt) =>
      val (hh *: tt, bh *: bt) = abcd
```
into
```scala
case abcd @ _:Tuple2[*:[h @ _, t @ _], *:[bh @ _, bt @ _]] =>
  val $1$: (Any, Tuple, Any, Tuple) =
    abcd:((T, M[T]) & (h *: t, bh *: bt)) @unchecked match 
      {
        case 
          Tuple2.unapply[T, M[T]](
            *:.unapply[Any, Tuple](hh @ _, tt @ _):(Any *: Tuple),
            *:.unapply[Any, Tuple](bh @ _, bt @ _):(Any *: Tuple))
            => Tuple4.apply[Any, Tuple, Any, Tuple](hh, tt, bh, bt)
      }
  val hh: Any = $1$._1
  val tt: Tuple = $1$._2
  val bh: Any = $1$._3
  val bt: Tuple = $1$._4
```
Before the change in #23923 it would
simplify `((T, M[T]) & (h *: t, bh *: bt))` into `(T & (h *: t), M[T] &
(bh *: bt))` and thus generate:
```scala
case abcd @ _:Tuple2[*:[h @ _, t @ _], *:[bh @ _, bt @ _]] =>
  val $1$: (h, t, bh, bt) =
    abcd:(T & h *: t, M[T] & bh *: bt) @unchecked match 
      {
        case 
          Tuple2.unapply[T & h *: t, M[T] & bh *: bt](
            *:.unapply[h, t](hh @ _, tt @ _),
            *:.unapply[bh, bt](bh @ _, bt @ _))
          => Tuple4.apply[h, t, bh, bt](hh, tt, bh, bt)
      }
  val hh: h = $1$._1
  val tt: t = $1$._2
  val bh: bh = $1$._3
  val bt: bt = $1$._4
```
Since it looks like this simplification is now illegal, and the unapply
generation for intersection types seems to prioritize the leftmost
argument, to fix this we make sure that when typing Binds we prioritize
the user-created `tree.tpe` and deprioritize the inferred proto type,
which hopefully is enough.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants