| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Favour module accessors symbols in rebind
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Refchecks tree transformer transforms a nested modules that
overrides a method into a pair of symbols: the module itself, and
an module accessor that matches the overridden symbol.
[[syntax trees at end of typer]] // test1.scala
package <empty> {
abstract trait C2 extends scala.AnyRef {
def O1: Any
};
class C1 extends AnyRef with C2 {
object O1 extends scala.AnyRef
}
}
[[syntax trees at end of refchecks]] // test1.scala
package <empty> {
abstract trait C2 extends scala.AnyRef {
def O1: Any
};
class C1 extends AnyRef with C2 {
object O1 extends scala.AnyRef
@volatile <synthetic> private[this] var O1$module: C1.this.O1.type = _;
<stable> def O1: C1.this.O1.type = {
C1.this.O1$module = new C1.this.O1.type();
C1.this.O1$module
}
}
}
When constructing a TypeRef or SingleType with a prefix and and a symbol,
the factory methods internally use `rebind` to see if the provided symbol
should be replaced with an overriding symbol that is available in that prefix.
Trying this out in the REPL is a bit misleading, because even if you change
phase to `refchecks`, you won't get the desired results because the transform
is not done in an InfoTransformer.
scala> val O1 = typeOf[C1].decl(TermName("O1"))
O1: $r.intp.global.Symbol = object O1
scala> typeRef(typeOf[C2], O1, Nil)
res13: $r.intp.global.Type = C2#O1
scala> res13.asInstanceOf[TypeRef].sym.owner
res14: $r.intp.global.Symbol = class C1
But debugging the test case, we get into `rebind` during an AsSeenFrom
which is where we crashed when `suchThat` encountered the overloaded
module and module accessor symbols:
typeOf[OuterObject.Inner.type].memberType(symbolOf[InnerTrait.Collection])
...
singleTypeAsSeen(OuterTrait.this.Inner.type)
val SingleType(pre, sym) = tp
// pre = OuterTrait.this.type
// sym = OuterTrait.Inner
val pre1 = this(pre) // OuterObject.type
singleType(pre1, sym)
rebind(pre1, sym) // was crashing, now OuterObject.Inner
}
This commit excludes the module symbol from symbol lookup in the prefix in rebind.
|
|\ \
| | |
| | | |
Update description of explicitouter phase.
|
| | |
| | |
| | |
| | | |
Patern translation now happens earlier.
|
|\ \ \
| |/ /
|/| | |
SI-7883 - don't iterate over all keys in MapWrapper.containsKey()
|
| | | |
|
|\ \ \
| | | |
| | | | |
Tests for protected access
|
| | | |
| | | |
| | | |
| | | |
| | | | |
I've marked a few minor cases in the test with !!! where I believe
the behaviour goes beyond the spec.
|
| | | |
| | | |
| | | |
| | | | |
c39f26382dddaa7 fixed the bug but didn't commit a test case.
|
|\ \ \ \
| | | | |
| | | | | |
Filter JVM debug output for custom options in partest
|
| | | | |
| | | | |
| | | | |
| | | | | |
The Picked up _JAVA_OPTIONS line occurs on Sun's JDK as a debug output when you use that variable to set up custom VM options
|
|\ \ \ \ \
| | | | | |
| | | | | | |
SI-6840 fixes weird typing of quasiquote arguments
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Previously quasiquote arguments were type checked against Any
which caused weird inference that made splicing of complex expressions
unusable:
val l1 = List(q"foo")
val l2 = List(q"bar")
q"f(..${l1 ++ l2})" // argument type checked as Any instead of List[Tree]
This is fixed by forcing compiler to type check against type
variable which itself isn't used in any other way.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
better macro impl shape errors
|
| |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
With the advent of quasiquotes, we allowed both arguments and return types
of macro impls to be c.Tree's (as opposed to traditional c.Expr[T]'s).
This warrants an update of macro def <-> macro impl signature mismatch
errors that include a printout of suggested macro impl signatures. Now
along with a signature that contains exprs, we suggest another signature
that has all exprs replaced by trees
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Deterministic warnings for pattern matcher, take 2
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The previous swing at determinism, ebb01e05cbe4, made decent
contact but apparently didn't hit it out of the park. The test
wavered every hundred or so runs, as witnessed occasionally in
nightly builds or pull request validation.
I setup a test to run neg/7020.scala a few hundred times, and
could trigger the failure reliably.
I then swept through the pattern matcher in search of HashMap and
HashSet creation, and changed them all to the Linked variety.
The results of that are published in retronym#ticket/7020-3 [1].
This commit represents the careful whittling down of that patch
to the minimal change required to exhibit determinism.
[1] https://github.com/retronym/scala/compare/ticket/7020-3
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | | |
SI-7519: Additional test case covering sbt/sbt#914
|
| | |/ / / / /
| |/| | | | | |
|
|\ \ \ \ \ \ \
| |_|_|_|_|_|/
|/| | | | | | |
fixes handling of fancy nested classes in runtime reflection
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Replaces the `jclazz.isMemberClass` check for whether we have an
inner/nested class with `jclazz.getEnclosingClass != null`, because there
exist classes produced by javac (see the attached jar file and the test log)
which have the following properties:
* They are nested within a parent class
* getEnclosingClass returns a non-null value
* isMemberClass returns false
Previously such classes were incorrectly treated as non-nested, were
incorrectly put into an enclosing package rather than an enclosing class,
and had their names trimmed in the process, leading to situations when
a package has multiple declarations with the same name. This is now fixed.
When changing the check, we need to be careful with interpretation of
what Class.getEnclosingXXX methods return. If getEnclosingClass produces
a non-null result, this doesn't mean that the class is inner or nested,
because getEnclosingClass is also not null for local classes (the ones
with getEnclosingMethod != null || getEnclosingConstructor != null).
This is expressed in the order of pattern match clauses in `sOwner`.
Now when the bug is fixed, I also revert b18a2f8798b2, restoring a very
important integrity check in runtime reflection, which I had to disable
a couple hours ago to fix a master breakage. More details at scala-internals:
https://groups.google.com/forum/#!topic/scala-internals/hcnUFk75MgQ
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This test has been a source of spurious failures as in, for example
https://github.com/scala/scala/pull/3029#issuecomment-26811129,
so I'm disabling it for the time being while I investigate the issue.
|
|\ \ \ \ \ \ \
| |_|_|/ / / /
|/| | | | | | |
deprecates raw tree manipulation facilities in macros.Context
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
test/disabled, not test/files/disabled.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
File.pathSeparator, rather than ":"
|
| |_|/ / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Removes the Unix-specific command-line sanity check put in place in recently
committed reflection tests.
On Windows, something like `C:\Java\jdk1.6.0_24-x64\jre\bin\java` might
be a valid command (pointing to `java.exe` or `java.bat`) even if
the eponymous file does not exist.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Add support for packages into quasiquotes and toolbox, improve handling of fresh names, unhardcode quasiquote expansion logic
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This should ensure that concurrent access to the
fresh name creator is properly synchronized.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
During parsing some names are generated artificially using freshTermName & freshTypeName (e.g. `x$1`). Such names should be reified in a different way because they are assumed to be always fresh and non-overlapping with the environment. So `x$1` should reify down to equivalent of `freshTermName("x$")` rather than `TermName("x$1")`.
But this is not enough. One name can be used more than once in a tree. E.g. `q"_ + 1"` desugars into `q"x$1 => x$1 + 1"`. So we need to ensure that every place where `x$1` is used gets the same fresh name. Hence the need for `withFreshTermName` that lets q"_ + 1" quasiquote desugare into equivalent of `withFreshTermName("x$") { freshx => q"$freshx => $freshx + 1" }`.
For pattern quasiquotes it's a bit different. Due to the fact that end-result must be a pattern we need to represent fresh names as patterns too. A natural way to express that something is fresh is to represent it as a free variable (e.g. any name will do in that place). But due to possible use of the same name in multiple places we need to make sure that all such places have the same values by adding a sequence of guards to the pattern.
Previously such names were reified naively and it could have caused name collision problems and inability to properly much on trees that contain such names.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Previously due to limited support for expansion in apply position
quasiquotes had to use a compiler hook for deconstruction. Now with
recent changes in pattern matcher it's possible to remove that special
case.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
In order to implement this a new parser entry point
`parseStatsOrPackages` that augments current parseStats with ability
to parse "package name { ... }" syntax.
|
| | | | | | | |
|
|\ \ \ \ \ \ \
| |_|_|/ / / /
|/| | | | | | |
Merge 2.10.x to master (again)
|
| |\ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
These are still impudently being non-deterministic.
I've reopened the ticket so we can take another swing at it.
A well targetted s/HashMap/LinkedHashMap/ will almost certainly
be the salve.
fail - neg/t7020.scala [output differs]% scalac t7020.scala
t7020.scala:3: warning: match may not be exhaustive.
It would fail on the following inputs: List((x: Int forSome x not in (1, 2, 4, 5, 6, 7))), List((x: Int forSome x not in (1, 2, 4, 5, 6, 7)), _), List(1, _), List(2, _), List(4, _), List(5, _), List(6, _), List(7, _), List(??, _), List(_, _)
List(5) match {
^
t7020.scala:10: warning: match may not be exhaustive.
It would fail on the following inputs: List((x: Int forSome x not in (1, 2, 4, 5, 6, 7))), List((x: Int forSome x not in (1, 2, 4, 5, 6, 7)), _), List(1, _), List(2, _), List(4, _), List(5, _), List(6, _), List(7, _), List(??, _), List(_, _)
List(5) match {
^
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Francois is investigating the root cause as part of his
work on stabilizing Scaladoc preview in the IDE.
The test seems to only fail on the windows nightly build.
I suspect this is due to a slower or loaded machine.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
https://github.com/scala/scala/pull/3029
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
not anymore
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
selfType joins the happy family of flags, annotations and privateWithin,
which automatically trigger initialization, when used within runtime
reflection.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
First of all, GIL should only apply to runtime reflection, because noone
is going to run toolboxes in multiple threads: a) that's impossible, b/c
the compiler isn't thread safe, b) ToolBox api prevents that.
Secondly, the only things in symbols which require synchronization are:
1) info/validTo (completers aren't thread-safe),
2) rawInfo and its dependencies (it shares a mutable field with info)
3) non-trivial caches like in typeAsMemberOfLock
If you think about it, other things like sourceModule or associatedFile
don't need synchronization, because they are either set up when a symbol
is created or cloned or when it's completed. The former is obviously safe,
while the latter is safe as well, because before acquiring init-dependent
state of symbols, the compiler calls `initialize`, which is synchronized.
We can say that symbols can be in four possible states: 1) being created,
2) created, but not yet initialized, 3) initializing, 4) initialized.
Of those only #3 is dangerous and needs protection, which is what this
commit does.
|
| | | | | | | | |
|
| |_|_|/ / / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The code to do so is curated with the help of a generator. Because this
needs to inspect code post-typer, the code generator is run during partest
as a code-validator. We could concievably do the same with a macro, but
this approach might be a better starting point which macros continue to
stabilize.
Removes Definitions.AnyRefModule and an already deprecated alias, as
these have been throwing exceptions for more than a year since 6bb5975289.
They used to be used by AnyRef specialization.
|
|\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | | |
SI-3346 implicit parameters can now guide implicit view inference
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This simple patch makes it possible for implicit views to benefit from
fundep-guided type inference, eliminating a nasty special case in
implicit inference.
Here are the changes that I had to apply to the tests (they exposed
quite a number of interesting questions that I was happy to answer):
1) neg/t5845.scala now works, so I moved it to pos. That easily makes sense,
because the test was just a canary to track previous state of things.
2) neg/divergent_implicit.scala, neg/t5578.scala and neg/t7519.scala
changed their messages to less informative ones, because inapplicable
implicit views now get disqualified early and therefore don't display
their error messages to the user. This is an unfortunate but necessary
byproduct of this change, and one can argue that the behavior is now
completely consistent with implicit vals (that also don't explain why
this or that implicit val got disqualified, but rather display a generic
implicit value not found message).
3) scaladoc/implicits-chaining.scala and scaladoc/implicits-base.scala.
Immediate culling of apriori inapplicable implicit views messes things up
for Scaladoc, because it's interested in potentially applicable views,
having infrastructure to track various constraints (type bounds, requirements
for implicit parameters, etc) that guide applicability of views and then
present it to the user. Therefore, when scaladoc is detected, implicit search
reverts to the old behavior.
4) We still cannot have Jason's workaround to type constructor inference
mentioned in comments to SI-3346, because it's not really about implicit
parameters of implicit views, but about type inference flowing from the
implicit parameter list to a preceding parameter list in order to affect
inference of an implicit view. This is something that's still too ambitious.
|