| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Improves name-based patmat.
|
| |
| |
| |
| |
| |
| | |
I discovered on erroneous code it could fall into a loop looking
for product selectors, because ErrorType always claims to have
whatever member you're asking about.
|
| |\
| | |
| | | |
SI-8128 Fix regression in extractors returning existentials
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The advent of the named based pattern matcher brought with it
a change in the way we determine the type of the value in the
"match monad". We used to take the base type to `Option` or `Seq`
(guided by the method name in `unapply` vs `unapplySeq`), and
simply use the type argument.
Name-based patmat, instead, uses the result type of methods in the
type. For example, the element type of an Option-like extractor
result is given by the result type of the no-args `get` method.
This approach, however, swiftly runs aground when navigating the
existential atolls. Here's why:
scala> class F[_]
defined class F
scala> val tp = typeOf[Some[F[X]] forSome { type X }]
warning: there were 1 feature warning(s); re-run with -feature for details
tp: $r.intp.global.Type = scala.this.Some[F[X]] forSome { type X }
scala> tp.baseType(typeOf[Option[_]].typeSymbol).typeArgs.head
res10: $r.intp.global.Type = F[X] forSome { type X }
scala> tp.memberType(tp.member(nme.get)).finalResultType
res11: $r.intp.global.Type = F[X]
`res10` corresponds to 2.10.x approach in `matchMonadResult`.
`res11` corresponds to the new approach in `resultOfMatchingMethod`.
The last result is not wrapped by the existential type. This results
in errors like (shown under -Ydebug to turn un accurate printing of
skolems):
error: error during expansion of this match (this is a scalac bug).
The underlying error was: type mismatch;
found : _$1&0 where type _$1&0
required: _$1
(0: Any) match {
^
one error found
This commit addresses the regression in 2.10.x compatible extractors
by using the 2.10 approach for them.
The residual problem is shown in the enclosed pending test.
|
| | |
|
| | |
|
| |
| |
| |
| | |
Test case for SI-8045, fixed by the preceding commits.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Name-based pattern matcher needed some hardening against
unapply methods with the right name but wrong types. Only
isEmpty methods which return Boolean are acceptable.
Catching it directly rather than indirectly also allowed
for better error messages.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This emerges from a recent attempt to eliminate pattern matcher
related duplication and to bake the scalac-independent logic
out of it. I had in mind something a lot cleaner, but it was
a whole lot of work to get it here and I can take it no further.
Key file to admire is PatternExpander.scala, which should
provide a basis for some separation of concerns.
The bugs addressed are a CCE involving Tuple1 and an imprecise
warning regarding multiple pattern crushing.
Editorial: auto-tupling unapply results was a terrible idea which
should never have escaped from the crib. It is tantamount to
purposely throwing type safety down the toilet in the very place
where people need type safety the most. See SI-6111 and SI-6675 for
some other comments.
|
|\ \
| | |
| | | |
junit test
|
| | | |
|
|\ \ \
| | | |
| | | | |
SI-8058 Better support for enum trees
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Replace the approach of “detect some magic combination of flags to
trigger some action” by introducing an enum flag which makes the
semantics and the intentions of the code using it more explicit.
This basically involves wiring up the existing ACC_ENUM bit to a new
modifier flag and making sure it is set correctly when encountering
enums.
The existing enum tests files/pos/t5165 and files/pos/t2764 keep
working, showing that this hasn't introduced any obvious regressions.
Tests for the changes in Namer which prevent scalac from messing with
enum trees can't be added yet, because one currently can't define an
enum in Scala without the help of the macro paradise.
The intention is to add the @enum macro as a full test suite as soon
as one can depend on macro annotations.
One might wonder why we don't check for
clazz.superClass == JavaEnumClass (where clazz is the owning class)
in isEnumConstant.
The reason is that this causes illegal cyclic reference error.
Explanation by Eugene why this happens:
(23:17:52) xeno_by: so here's what happens as far as I can understand at 11pm :)
(23:18:09) xeno_by: scalac tries to complete the signature of the newly expanded class
(23:18:11) xeno_by: to do that
(23:18:40) xeno_by: to do that it needs three things
(23:18:51) xeno_by: because the signature of a class is ClassInfoType which consists of three things
(23:19:05) xeno_by: parents
(23:19:08) xeno_by: decls
(23:19:09) xeno_by: and symbol
(23:19:20) xeno_by: symbol is easy - it's already there
(23:19:30) xeno_by: parents are also easy
(23:19:39) xeno_by: you just typecheck the things that come after "extends"
(23:19:42) xeno_by: but decls are tricky
(23:19:51) xeno_by: scalac goes through all the members of the class
(23:20:03) xeno_by: and doesn't typecheck them... no, it doesn't
(23:20:07) xeno_by: it just enters them
(23:20:32) xeno_by: i.e. creates symbols for them and assigns lazy completers to those symbols so that if someone wants to know their signatures, they will go through the completers
(23:20:34) xeno_by: and then
(23:20:38) xeno_by: wait
(23:20:40) xeno_by: there's one but
(23:20:42) xeno_by: BUT
(23:20:47) xeno_by: while we enter those symbols
(23:20:53) xeno_by: our ClassInfoType is not ready yet
(23:21:09) xeno_by: the class we're completing is still considered to be in the middle of being completing
(23:21:12) xeno_by: so
(23:21:24) xeno_by: when inside enterSym you try to ask that class for its super class
(23:21:35) xeno_by: what happens is that check asks the class for its type signature
(23:21:45) xeno_by: the ClassInfoType that consists of parents and decls
(23:21:54) xeno_by: even though the parents are already calculated
(23:22:01) xeno_by: the ClassInfoType as a whole is not
(23:22:16) xeno_by: so scalac says that you're trying to complete something that's currently being completed
(23:22:20) xeno_by: cyclic reference error
(23:22:59) xeno_by: "cyclic" in English looks an awful lot like "суслик" in Russian (which means "gopher")
|
|\ \ \ \
| | | | |
| | | | | |
CLI help update for -Xplugin
|
| |/ / /
| | | |
| | | |
| | | |
| | | | |
The argument to `-Xplugin` is now a comma-separated list of paths.
This commit updates the option descriptor and a code comment.
|
|\ \ \ \
| | | | |
| | | | | |
SI-8046 BaseTypeSeq fixes with aliases
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We can only compute the base type sequence (BTS) of a `TypeRef` by
element-wise transforming the BTS of the referenced symbol if
there are no abstract types in its BTS type symbols.
In the now-working test case, `pos/t8046.scala`, the difference
between the old and new calculation of the BTS is:
this = Three.this.Alias[Int]
sym.info.baseTypeSeq = BTS(One.this.Op[A],Any)
mapped BTS = BTS(Three.this.Op[Int],Any)
full BTS = BTS(Three.this.Op[Int],Int => Int,Object,Any)
The change to account for PolyType in ArgsTypeRef#transform is now
needed to avoid the full BTS of:
BTS(Three.this.Op[A],A => A,Object,Any)
Interestingly, everything actually works without that change.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Not solved with base type dealiasing
|
| | | | | |
|
|\ \ \ \ \
| |_|_|/ /
|/| | | | |
SI-2066 Plug a soundness hole higher order type params, overriding
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
PolyType-s parameterized by higher order type parameters (HOTPs)
should only be relatable with <:< or =:= if the variances of their
type parameters line up. This is only enforced for HOTPs defined in
method type arguments.
Invariant type parameters subsume variant ones. Concretely, as
described by @S11001001:
> A method taking [F[_]] can implement a method taking [F[+_]].
> Likewise, a method taking [F[_[+_]]] can implement a method
> taking [F[_[_]]], as with [F[_[_[_]]]] implementing [F[_[_[+_]]]],
> and so on, the variance subsumption flipping at each step.
>
> This is just the opposite of the variance for passing type
> parameters to either instantiate types or call methods; a F[+_]
> is a suitable F[_]-argument, a F[_[_]] a suitable F[_[+_]]-argument,
> and so on.
>
> All of the above rules can be duplicated for contravariant positions
> by substituting - for +. Also, something similar happens for
> weakening/strengthening bounds, I believe.
These cases are tested in the `// okay` lines in `neg/t2066.scala`.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Fixes SI-6615, NPE on slice of PagedSeq.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
been computed yet
Made sure to addMore when roving forward on a slice into unpaged territory.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Resolves SI-6364, O(n) performance of wrapped set contains.
|
| |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
O(n) performance of wrapped set contains was the problem.
Added overrides for contains and isEmpty to SetWrapper. Note that sets are
invariant in Scala, while the Java signature is for any Object, so we trap
a ClassCastException if one occurs. (Is this everything that could possibly
go wrong? I think so, but am not as confident as I would like.)
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Update the ScalaDoc entry page of the Scala library
|
| | | | | | | |
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
Fixes #3330 with Scaladoc changes only
|
| | |_|_|_|/ /
| |/| | | | | |
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-8129 Plug a leak in perRunCaches
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
I guess we've never leaned to heavily on these, because the
registry of caches was forgetting about most of them
immediately if they compared == at the point of creation.
Consequently, maps like `treatedInfos` in Mixin were holding
onto old types and symbols and leaking memory.
You can reproduce the leak with:
(for i in {1..200}; do echo src/library/scala/collection/*.scala; done; printf "\n") | scalac-hash v2.11.0-M7 -J-Xmx256M -Xresident
nsc> warning: there were 6 deprecation warning(s); re-run with -deprecation for details
(... 15 times)
nsc> java.lang.OutOfMemoryError: GC overhead limit exceeded
Dumping heap to java_pid90362.hprof ...
Heap dump file created [340635728 bytes in 7.993 secs]
^CException in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
As a consequence of this change, I had to remove eager clearing of the
uniques types cache. The comment in the code elaborates further.
|
|\ \ \ \ \ \ \ \
| | | | | | | | |
| | | | | | | | | |
fixes run/macroPlugins-namerHooks.scala
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Makes run/macroPlugins-namerHooks.scala work equally well on both
Unix and Windows machines.
|
|\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
SI-8131 Move test for reflection thread safety to pending.
|
| |/ / / / / / / /
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Examples noted in SI-8131 show that race conditions still abound.
This has been noted twice during pull request validation.
|
|\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
SI-8135 Disabled flaky hyperlinking presentation compiler test
|
|/ / / / / / / / /
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
This PR (https://github.com/scala/scala/pull/3275#issuecomment-31986434)
demonstrates that the test is flaky.
The disabled test was introduced with the intent of preventing a
regression (here is the commit
https://github.com/scala/scala/commit/ccacb06c4928fd6aebc2c2539d7565cb079dc625).
It looks like there is a race condition when `askTypeAt(pos)` is called
on `implicitly[Foo[A]].foo` where `pos` is matches the end point of the
former expression. The issue is that the returned Tree is unattributed,
which is why the error "No symbol is associated with tree
implicitly[Foo[A]].foo" is reported.
|
|\ \ \ \ \ \ \ \ \
| | | | | | | | | |
| | | | | | | | | | |
Fix SI-7443 Range.sum ignoring Numeric argument and always assuming default 'plus' implementation
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Previously both Range and NumeriRange used formula for sum of elements
of arithmetic series and thus always assumed that provided Numeric is
regular one.
Bug is now fixed by conservatively checking if Numeric is one of
default ones and the formula still holds.
|
|\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | | |
Update man pages for scala and scalac.
|
| | |_|_|/ / / / / /
| |/| | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
They had fallen quite a bit behind the output of
"scalac -X" and "scalac -Xshow-phases".
|
|\ \ \ \ \ \ \ \ \ \
| | | | | | | | | | |
| | | | | | | | | | | |
Scala dist maven
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
To avoid duplication in scala/scala-dist, where it'll just go stale.
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Duplicated from scala-compiler's pom (where it's optional),
so that resolving scala-dist's transitive dependencies include jline.
We won't see scala-compiler's optional dependency on jline when depending on
scala-compiler.
TODO: remove duplication once we have the scala-compiler-repl module
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
If you'd rather depend on all Scala has to offer, module-wise,
depend on scala-library-all. This dependency determines the
jars that ship with the Scala distribution. To achieve parity
via maven resolution, this is the artifact to depend on.
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
We now publish a scala-dist artifact every time we publish to maven.
It captures everything needed to build a Scala distribution.
The packager should resolve all transitive dependencies of scala-dist,
put the class-file jars in the lib/ directory,
the scaladoc jars in the api/ directory,
and the source jars in the src/ directory,
in addition to unpacking the scala-dist jar itself,
which contains the bin/, doc/ and man/ directories,
which previously weren't available on maven.
This also removes the `@{dir}` abstraction, which was used to
package the continuations plugin. Since it's moved out,
we can go back to hard-coding it.
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
NOTE: `maven/latest/build.xml` is now deprecated.
To publish a Scala build, simply call `ant publish` or `ant publish-local`.
`maven/latest/build.xml` will soon disappear from `dists/`
The idea is that a Scala distribution is a simple
repackaging of artifacts already available on maven.
Already available: typical jars for the artifacts (classes, sources, scaladoc).
To add: the bin/, doc/, and man/ directories.
Thus, move the contents that should end up in the distribution
from docs/ to doc/, create the man/ directory with the manpages,
and include the scripts in bin/.
Next up: package these directories in a jar and publish to maven,
with a dependency on scala-library-all, scala-reflect and scala-compiler,
for the jars that should end up in the distribution.
Refactorings:
- Pull filter-pom out from deploy-one.
- Rename maven-base to dist.maven.
- Set all properties in the init target (dist.maven)
|
| | | | | | | | | | | |
|