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

Add append operator to Tuple #13775

Closed
wants to merge 79 commits into from
Closed

Conversation

danicheg
Copy link
Contributor

Currently, Tuple has the prepend operator only.

@nicolasstucki nicolasstucki self-assigned this Oct 20, 2021
Copy link
Contributor

@nicolasstucki nicolasstucki left a comment

Choose a reason for hiding this comment

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

Otherwise LGTM

Could you also rebase and squash the commits?

object Test {
def main(args: Array[String]): Unit = {
def testArray[T: ClassTag](n: Int, elem: Int => T): Unit = {
val t: Int *: Tuple = 0 *: Tuple.fromArray(Array.tabulate(n)(elem))
Copy link
Contributor

Choose a reason for hiding this comment

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

This prepend 0 seems to be a left over form the prepend test

Suggested change
val t: Int *: Tuple = 0 *: Tuple.fromArray(Array.tabulate(n)(elem))
val t: Int *: Tuple = Tuple.fromArray(Array.tabulate(n)(elem))

unkarjedy and others added 26 commits October 21, 2021 12:52
Consider the example:
```scala
for {
  x <- 1 to 5
  if true; if true; if true
} yield x
```
Note, that multiple if guards start from a new line and are not separated with a semicolon or a new line.
This code is compiled ok in Scala 3 and is a valid code according to Scala 2 syntax reference:
(though looks like there is a bug in implementation scala/bug#12323)

But it's not supported according to the Scala 3 syntax reference.

related issues:
scala/bug#12323
https://youtrack.jetbrains.com/issue/SCL-13220
Co-authored-by: Jamie Thompson <bishbashboshjt@gmail.com>
Co-authored-by: Jamie Thompson <bishbashboshjt@gmail.com>
The added test case shows how the current implementation handles variance of match types. This PR updates the correponding documentation which was outdated.
fixes scala#10383

Co-authored-by: Dale Wijnand <dale.wijnand@gmail.com>
This allows REPL to input extensions.
This makes it closer to the Scala Symposium 21 paper.
Otherwise, the symbol denotations are not update to date: some
synthetic members are missing, thus static method resolution produces
incorrect result.
liufengyun and others added 27 commits October 21, 2021 12:52
The following test explodes: tests/init/pos/local-warm5.scala.

Ideally we should use an actual set in RefSet, which we don't do for
both performance and determinism. The performance concern might be a
premature optimization.
Use correct klass for evaluating rhs of local variables.
Co-authored-by: Ondřej Lhoták <olhotak@uwaterloo.ca>
Co-authored-by: Natsu Kagami <natsukagami@gmail.com>
Now, everything goes through the extension methods in JSSymUtils.
Previously, we tested whether the default accessor itself had the
`@js.native` annotation. That is however never the case. Instead,
we now test whether the associated method has the annotation.

We still emit the *definitions* of those default accessors, even
though that they are never called anymore, because of backward
binary compatibility. If we stopped emitting them, a library
compiled with a newer Scala.js might not link anymore against an
application built with a previous Scala.js.

This is a forward port of
scala-js/scala-js@7e998b4
The default accessors matching that property are not emitted
anymore. This is similar to how default accessors for JS native
constructors are not emitted.

Unfortunately, for backward binary compatibility reasons, we must
still emit default accessors of JS native defs that are anything
else than `= js.native`. Until Scala.js 1.7.0, those default
accessors would actually be referenced by calling code (see
scala-js/scala-js#4554),
so removing them now would create dangling references.

This is a forward port of
scala-js/scala-js@e01dc1a
Nor for their default param accessors.

This is a forward port of
scala-js/scala-js@a95f3f6
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.