| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
A minor evolution of the notion of completion + also a small performance
optimization.
|
|
|
|
|
|
| |
This reverts commit 000c18a8fac60065747652368dadcd7850532f3f,
because Symbol.isStable is independent from Type.isVolatile
since fada1ef6b315326ac0329d9e78951cfc95ad0eb0.
|
|
|
|
|
| |
No changes to behavior, just documenting internal workings of reflection
a bit more thoroughly, one step at a time.
|
|\
| |
| | |
Removes TODO comments that are no longer applicable
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- we do not want to use mutable updates because that would mean making vals
vars, losing various guarantees for final fields of the java memory model
- we do not want to add more subcasses of HashSet, because that would make
callsites megamorphic. If anything, we should try to reduce the number of
subclasses
- checking for monomorphic call site is not worth it for a single virtual
method call.
|
|\ \
| | |
| | | |
reshuffles names for blackbox/whitebox contexts, changes bundle notation
|
| | |
| | |
| | |
| | |
| | |
| | | |
This code is currently unused, so I’m removing it in order to avoid bitrot.
Once we’re sure that we can trust Scala reflection with our macros, the
removed file can be easily reinstated.
|
| | |
| | |
| | |
| | |
| | |
| | | |
As per Jason’s feedback, this commit handles overloaded constructors
in macro bundles. The backend now checks that we have a constructor of
a correct type. The frontend now prohibits multiple constructors altogether.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Adjusts bundle notation to read `class Bundle(val c: Context)` instead of
`class Bundle extends Macro`. This avoids calling compileLate in the
macro compiler and associated tooling problems.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Performs the following renamings:
* scala.reflect.macros.BlackboxContext to scala.reflect.macros.blackbox.Context
* scala.reflect.macros.BlackboxMacro to scala.reflect.macros.blackbox.Macro
* scala.reflect.macros.WhiteboxContext to scala.reflect.macros.whitebox.Context
* scala.reflect.macros.WhiteboxMacro to scala.reflect.macros.whitebox.Macro
https://groups.google.com/forum/#!topic/scala-internals/MX40-dM28rk
|
|\ \ \
| | | |
| | | | |
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.
|