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 Changes from Dotty Upstream #38

Merged
merged 58 commits into from Nov 4, 2019

Conversation

noti0na1
Copy link
Collaborator

@noti0na1 noti0na1 commented Nov 4, 2019

Fix a syntax error in DottyPredef
def (x: T|Null) nn[T]: T -> def[T] (x: T|Null) nn: T

anatoliykmetyuk and others added 30 commits September 20, 2019 15:30
The new syntax has the type parameters come first. I.e.
```
  def [T](xs: List[T]) append (ys: List[T]): List[T] = ...
```
instead of
```
  def (xs: List[T]) append [T] (ys: List[T]): List[T] = ...
```
Application is unchanged, so it is still
```
  xs.append[String](ys)
```
An argument for the old syntax is that it aligns definition and call syntax.
On the other hand, the new syntax maintains the general rule that parameter introductions
always com before parameter uses. The decisive argument to switch is to be consistent
with the new collective parameter syntax, where `append` would be written like this:
```
  given [T](xs: List[T])
    def append (ys: List[T]): List[T] = ...
```
To avoid misalignment of type parameters between definition and call syntax, we considered
disallowing explicit type parameters for extension methods altogether, and to require
that the method is called as a normal method instead. But that would not work for anonymous
givens as in the last exaple above.
Fix scala#7421: Insert missing <outdent> tokens where a region ends
Part of the effort documented in scala#1589 to port all error messages to
the new scheme.
I wanted to get the test in anyway and this will hopefully get the CI unstuck.
…rams

Syntax change for type parameters of extension methods
Fix scala#7438: Turn failing assertion into error in inliner
This was done on Tree an all other types in TASTy reflect but we forgot to do it for Type
This does not affect pattern matching exhaustivity (yet) since currently
only abstract sealed classes and sealed traits are checked for exhaustivity,
so defualt classes do not count. I wonder whether we should change that (?).
Also, make all synthetic classes produced in Definitions Open.
Indicate OS support in requirements
anatoliykmetyuk and others added 28 commits October 30, 2019 13:58
It was needed to make Dotty cross-compile to Scala 2
before full bootstrap. Its direct semantics
is about adding the `inline` flag to a symbol
annotated by it. `inline` flag, however, is listed as
one of the flags that are not supposed to be modified
by completion of symbols. Hence, having `forceInline`
annotation is in violation of our own assumptions
about completion. Before full bootstrap, we were not
able to drop this annotation, however, now that we
have the full bootstrap, we can do it.
…t-type

Extract modules in reflection Type
Fix scala#7189: Do not try to load contents if file does not exist
Fix scala#7459: Fix two crash conditions in Inliner
Classes representing sum types need to be be abstract, which default classes are not.

This partially reverts "Treat non-open classes as effectively sealed."
d98c2d6.
…erence

Port "illegal cyclic type reference" error to new scheme
…-RC1

Upgrade Dotty Reference to 0.20.0-RC1
escape quote characters in interpolations with $
Previously, when using worksheets, the evaluated code would move to the
next line when adding a new line. Now, the evaluated code stays on the
original line.
Don't move worksheet decoration when adding new line
@abeln abeln merged commit 946a7a9 into abeln:dotty-explicit-nulls Nov 4, 2019
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.

None yet