Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge 3.3.0 reference #17587

Merged

Conversation

Kordyjan
Copy link
Contributor

No description provided.

odersky and others added 30 commits January 12, 2023 10:51
Reduces number of type parameters in boundary from 2 to 1
Note that this does not rewrite to labeled returns yet because of some
inlining limitations.
Co-authored-by: Guillaume Martres <[email protected]>
The test was minimized too far and did not actually have a stack
size issue. Also added a test when in a local `def` and made the
comment for the `lazy val` case more accurate.
… owner (also fix false positive for enum) (scala#16661)

This solves the issue scala#16650.

The issue is that `member(sym.name)` failed to resolve when a type
contains multiple identical name. Here the `dotty.tools.dotc.util`
package contains multiple "<init>" (constructor), so `member` fail to
resolve the name

The solution is to register the owner of the contructor instead of the
constructor itself.

:warning: I couldn't create a test where this appends, I tested it by
`publishLocal` and testing the code in a different project with this
code from scala#16650 (also didn't check on the metals build):
```scala
//> using lib "org.scala-lang::scala3-compiler:3.3.0-RC1-bin-20230109-f56089b-NIGHTLY"
//> using scala "3.3.0-RC1-bin-20230109-f56089b-NIGHTLY"
//> using option "-Wunused:all"

import dotty.tools.dotc.util.LinearSet

@main
def run = 
  val a = 123
  println("Hello!")
```
```bash
sbt> run
[info] compiling 1 Scala source to .../target/scala-3.3.0-RC1-bin-SNAPSHOT/classes ...
[warn] -- Warning: ..../src/main/scala/Main.scala:5:29 
[warn] 5 |import dotty.tools.dotc.util.LinearSet
[warn]   |                             ^^^^^^^^^
[warn]   |                             unused import
[warn] -- Warning:.../src/main/scala/Main.scala:10:6 
[warn] 10 |  val a = 123
[warn]    |      ^
[warn]    |      unused local definition
[warn] two warnings found
[info] running run 
Hello!
```
### EDIT
Also add a related fix for import generated by enum (false positive)
* Simplify the flow for most common kinds of release/commit validation -
compiling and running sources
* Allow specifying a range of releases to bisect with `--releases` flag
(needed for finding regressions in features introduced after 3.0.0)
* Automatically assert correctness of the validation script - it should
succeed for the first validated release and fail for the last one
* Add dry run mode (`--dry-run` flag) to check the validation script
without running the entire bisection
* Use `--server=false` in scala-cli by default
* this avoids false negatives of validation failing for some compiler
versions for which it should succeed but fails because of some
zinc/scala-cli related errors
* this allows using a non-bootstrapped compiler for testing, which
significantly speeds up `publishLocal`; non-boostrapped is now the
default, bootstrapped can be turned on with `--bootstrapped` flag
Only check trees if there is an enclosing boundary
We track in a new variable `stackHeight` the number of stack slots
that are "on hold" while loading some other tree. When we
immediately consume stack elements without using `genLoad` on top,
we do not need to update `stackHeight`.

We store the target `stackHeight` of labels in their
`LoadDestination.Jump`. This way, when we generate a jump, we can
compute the difference and drop the excess stack.
The back-end can now handle labeled-returns across stack
differences, so we can emit optimized blocks even in those
situations.
scala#702 introduced a requirement that self types are closed. This means

> If trait X has self type S and C is a class symbol of S, then S also
conforms
to the self type of C.

An example that violates this requirement is
```scala
trait X { self: Y => } // error: missing requirement: self type Y & X of trait X does not conform to self type Z of required trait Y
trait Y { self: Z => }
trait Z
```
But it's no longer clear what the requirement should achieve. If we let
the example above typecheck and try to implement X with something like
```scala
class C extends X, Y
```
we would at that point get an error saying that `C` does not conform to
the self type Z of Y. So it would have to be
```scala
class C extends X, Y, Z
```
and this one looks fine.

The original change in scala#702 was made to avoid a crash in
pending/run/t7933.scala. Unfortunately, we cannot reproduce this anymore
since it depends on nsc.interpreter, which is no longer part of Scala
2.13.

Since we are no longer sure what the restriction should achieve I think
it's better to drop it for now. If people discover problems with code
that uses "open" self types, we can try to fix those problems, and if
that does not work, would fallback re-instituting the restriction. It's
not ideal, but I don't see another way.

Fixes scala#16407
Enable the addition of classes from a `MacroAnnotation`:
* Can add new `class`/`object` definitions next to the annotated
definition

Special cases:
* An annotated top-level `def`, `val`, `var`, `lazy val` can return a
`class`/`object`
   definition that is owned by the package or package object.

Related PRs:
 * Follows scala#16454
…dled-by-backend

Add errorhandling stack handled by backend
Kordyjan and others added 18 commits April 27, 2023 00:44
In code like:

    class Outer:
      sealed trait Foo
      case class Bar() extends Foo

      def mat(foo: Foo) = foo match
        case Bar() =>

When in the course of decomposing the scrutinee's type, which is
`Outer.this.Foo`, we're trying to instantiate subclass `Outer.this.Bar`,
the `Outer.this` is fixed - it needn't be inferred, via type variables
and type bounds.  Cutting down on type variables, particularly when GADT
symbols are also present, can really speed up the operation, including
making code that used to hang forever compile speedily.
…n other than a variable or a number literal.

This partially reverts the changes from scala#16150.
This change is motivated by not breaking source compatibility for a number of projects in the Open Community Build.
…uage specification

* Make the parser's warning a migration warning
@Kordyjan Kordyjan mentioned this pull request May 25, 2023
57 tasks
Copy link
Contributor

Choose a reason for hiding this comment

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

I am not sure about the changes in this file. @bishabosha could you please double check?

Copy link
Member

@bishabosha bishabosha May 25, 2023

Choose a reason for hiding this comment

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

this change is ok, (all I see is h3 titles changing to h2)

Copy link
Member

@bishabosha bishabosha left a comment

Choose a reason for hiding this comment

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

we really should update https://github.com/lampepfl/dotty/blob/release-3.3.0/docs/_docs/reference/language-versions/source-compatibility.md to list -source 3.3 and -source 3.3-migration modes

I know that we can always post-hoc merge to language-reference-stable, but does the 3.3.0 reference in the version picker only get published once? or is it always published until the next stable release?

@Kordyjan Kordyjan requested a review from bishabosha May 29, 2023 14:26
@Kordyjan
Copy link
Contributor Author

I don't think we have a version picker for the language reference. It exists only for API docs.
Language ref is always synchronized with language-reference-stable.

@Kordyjan Kordyjan marked this pull request as ready for review May 29, 2023 14:35
@Kordyjan Kordyjan merged commit 8810943 into scala:language-reference-stable May 30, 2023
@Kordyjan Kordyjan deleted the merge-3.3.0-reference branch May 30, 2023 07:24
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.