| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under `-Ydelambdafy:method`, a public, static accessor method is
created to expose the private method containing the body of the
lambda.
Currently this accessor method has its parameters in the same order
structure as those of the lambda body method.
What is this order? There are three categories of parameters:
1. lambda parameters
2. captured parameters (added by lambdalift)
3. self parameters (added to lambda bodies that end up in trait
impl classes by mixin, and added unconditionally to the static
accessor method.)
These are currently emitted in order #3, #1, #2.
Here are examples of the current behaviour:
BEFORE (trait):
```
% cat sandbox/test.scala && scalac-hash v2.11.5 -Ydelambdafy:method sandbox/test.scala && javap -private -classpath . 'Test$class'
trait Member; class Capture; trait LambdaParam
trait Test {
def member: Member
def foo {
val local = new Capture
(arg: LambdaParam) => "" + arg + member + local
}
}
Compiled from "test.scala"
public abstract class Test$class {
public static void foo(Test);
private static final java.lang.String $anonfun$1(Test, LambdaParam, Capture);
public static void $init$(Test);
public static final java.lang.String accessor$1(Test, LambdaParam, Capture);
}
```
BEFORE (class):
```
% cat sandbox/test.scala && scalac-hash v2.11.5 -Ydelambdafy:method sandbox/test.scala && javap -private -classpath . Test
trait Member; class Capture; trait LambdaParam
abstract class Test {
def member: Member
def foo {
val local = new Capture
(arg: LambdaParam) => "" + arg + member + local
}
}
Compiled from "test.scala"
public abstract class Test {
public abstract Member member();
public void foo();
private final java.lang.String $anonfun$1(LambdaParam, Capture);
public Test();
public static final java.lang.String accessor$1(Test, LambdaParam, Capture);
}
```
Contrasting the class case with Java:
```
% cat sandbox/Test.java && javac -d . sandbox/Test.java && javap -private -classpath . Test
public abstract class Test {
public static class Member {};
public static class Capture {};
public static class LambaParam {};
public static interface I {
public abstract Object c(LambaParam arg);
}
public abstract Member member();
public void test() {
Capture local = new Capture();
I i1 = (LambaParam arg) -> "" + member() + local;
}
}
Compiled from "Test.java"
public abstract class Test {
public Test();
public abstract Test$Member member();
public void test();
private java.lang.Object lambda$test$0(Test$Capture, Test$LambaParam);
}
```
We can see that in Java 8 lambda parameters come after captures. If we
want to use Java's LambdaMetafactory to spin up our anoymous FunctionN
subclasses on the fly, our ordering must change.
I can see three options for change:
1. Adjust `LambdaLift` to always prepend captured parameters,
rather than appending them. I think we could leave `Mixin` as
it is, it already prepends the self parameter. This would result
a parameter ordering, in terms of the list above: #3, #2, #1.
2. More conservatively, do this just for methods known to hold
lambda bodies. This might avoid needlessly breaking code that
has come to depend on our binary encoding.
3. Adjust the parameters of the accessor method only. The body
of this method can permute params before calling the lambda
body method.
This commit implements option #2.
In also prototyped #1, and found it worked so long as I limited it to
non-constructors, to sidestep the need to make corresponding
changes elsewhere in the compiler to avoid the crasher shown
in the enclosed test case, which was minimized from a bootstrap
failure from an earlier a version of this patch.
We would need to defer option #1 to 2.12 in any case, as some of
these lifted methods are publicied by the optimizer, and we must
leave the signatures alone to comply with MiMa.
I've included a test that shows this in all in action. However, that
is currently disabled, as we don't have a partest category for tests
that require Java 8.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I removed the `-bcode` test since we have a build that passes
`-Ybackend:GenBCode` to all tests.
Short intro do the [`InnerClass` attribute][1]:
- A class needs one `InnerClass` attribute for each of its nested
classes
- A class needs the `InnerClass` attribute for all (nested) classes
that are mentioned in its constant pool
The attribute for a nested class `A$B$C` consists of the long name of
the outer class `A$B`, the short name of the inner class `C`, and
an access flag set describig the visibility.
The attribute seems to be used for reflection.
[1]: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.6
|
|
|
|
|
| |
As seen in a runtime reflection failure in Slick during a GenBCode
enabled run of our beloved Community Build.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit a02e053a5dec134f7c7dc53a2c1091039218237d.
That commit lead to an error compiling Specs2:
[info] [warn] /localhome/jenkinsdbuild/workspace/Community-2.11.x-retronym/dbuild-0.7.1-M1/target-0.7.1-M1/project-builds/specs2-aaa8091b47a34817ca90134ace8b09a9e0f854e9/core/src/test/scala/org/specs2/text/EditDistanceSpec.scala:6: Unused import
[info] [warn] import DiffShortener._
[info] [warn] ^
[info] [error] /localhome/jenkinsdbuild/workspace/Community-2.11.x-retronym/dbuild-0.7.1-M1/target-0.7.1-M1/project-builds/specs2-aaa8091b47a34817ca90134ace8b09a9e0f854e9/core/src/test/scala/org/specs2/text/LinesContentDifferenceSpec.scala:7: exception during macro expansion:
[info] [error] java.lang.UnsupportedOperationException: Position.point on NoPosition
[info] [error] at scala.reflect.internal.util.Position.fail(Position.scala:53)
[info] [error] at scala.reflect.internal.util.UndefinedPosition.point(Position.scala:131)
[info] [error] at scala.reflect.internal.util.UndefinedPosition.point(Position.scala:126)
[info] [error] at org.specs2.reflect.Macros$.sourceOf(Macros.scala:25)
[info] [error] at org.specs2.reflect.Macros$.stringExpr(Macros.scala:19)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When producing an initial spec for macros two years ago, we sort of glossed
over named/default arguments in macro applications, leaving them for future work.
Once the aforementioned future has come, I’ve made several attempts at
making things operational (e.g. last summer), but it’s always been unclear
how to marry the quite complex desugaring that tryNamesDefaults performs
with the expectations of macro programmers to see unsugared trees
in macro impl parameters.
Here’s the list of problems that arise when trying to encode named/default
arguments of macro applications:
1) When inside macro impls we don’t really care about synthetic vals
that are typically introduced to preserve evaluation order in non-positional
method applications. When we inline those synthetics, we lose information
about evaluation order, which is something that we wouldn’t like to lose
in the general case.
2) More importantly, it’s also not very exciting to see invocations of
default getters that stand for unspecified default arguments. Ideally,
we would like to provide macro programmers with right-hand sides of those
default getters, but that is: a) impossible in the current implementation
of default parameters, b) would anyway bring scoping problems that we’re
not ready to deal with just yet.
Being constantly unhappy with potential solutions to the aforementioned
problems, I’ve been unable to nail this down until the last weekend,
when I realized that: 1) even though we can’t express potential twists in
evaluation order within linearly ordered macro impl params, we can use
c.macroApplication to store all the named arguments we want, 2) even though
we can’t get exactly what we want for default arguments, we can represent
them with EmptyTree’s, which is not ideal, but pretty workable. That’s
what has been put into life in this commit.
As a pleasant side-effect, now the macro engine doesn’t have to reinvent
the wheel wrt reporting errors about insufficient arg or arglist count.
Since this logic is intertwined with the tryNamesDefaults desugaring,
we previously couldn’t make use of it and had to roll our own logic
that checked that the number of arguments and parameters of macro applications
correspond to each other. Now it’s all deduplicated and consistent.
|
|\
| |
| | |
kills resetAllAttrs
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit removes resetAllAttrs from the public reflection API.
This method was previously deprecated, but on a second thought that
doesn't do it justice. People should be aware that resetAllAttrs is just
wrong, and if they have code that uses it, this code should be rewritten
immediately without beating around the bush with deprecations. There's
a source-compatible way of achieving that (resetLocalAttrs), so that
shouldn't bring much trouble.
Secondly, resetAllAttrs in compiler internals becomes deprecated. In subsequent
commits I'm going to rewrite the only two locations in the compiler that
uses it, and then I think we can remove it from the compiler as well.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Apparently some completers can call setInfo while they’re not yet done,
which resets the LOCKED flag, and makes anything that uses LOCKED to
track completion unreliable. Unfortunately, that’s exactly the mechanism
that was used by runtime reflection to elide locking for symbols that are
known to be initialized.
This commit fixes the problematic lock elision strategy by introducing
an explicit communication channel between SynchronizedSymbol’s and their
completers. Now instead of trying hard to infer whether it’s already
initialized or not, every symbol gets a volatile field that can be queried
to provide necessary information.
|
|/
|
|
|
|
|
|
| |
Depending on the environment in which the test is run, s1 can be either
“String” or “java.lang.String”. This is one of the known non-deterministic
behaviors of our reflection, caused by prefix stripping only working for
packages defined in the root mirror. Until we fix this, I suggest we make
the test more lenient.
|
|\
| |
| | |
reshuffles names for blackbox/whitebox contexts, changes bundle notation
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
| |
Examples noted in SI-8131 show that race conditions still abound.
This has been noted twice during pull request validation.
|
|
|
|
|
| |
This method has always been slightly bothering me, so I was really glad
when Denys asked me to rename it. Let’s see how it pans out.
|
| |
|
|\
| |
| | |
SI-6385 Avoid bridges to identical signatures over value classes
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As Paul noted in the comments to SI-6260 (from which I mined some
test cases) "there is no possible basis for conflict here":
scala> class C[A](val a: Any) extends AnyVal
defined class C
scala> class B { def x[A](ca: C[A]) = () }
defined class B
scala> class D extends B { override def x[A](ca: C[A]) = () }
<console>:8: error: bridge generated for member method x: [A](ca: C[A])Unit in class D
which overrides method x: [A](ca: C[A])Unit in class B
clashes with definition of the member itself;
both have erased type (ca: Object)Unit
class D extends B { override def x[A](ca: C[A]) = () }
^
What was happening?
Bridge computation compares `B#x` and `D#x` exitingErasure, which
results in comparing:
ErasedValueType(C[A(in B#x)]) =:= ErasedValueType(C[A(in D#x)])
These types were considered distinct (on the grounds of the unique
type hash consing), even though they have the same erasure and
involve the same value class.
That triggered creation of an bridge. After post-erasure eliminates
the `ErasedValuedType`s, we find that this marvel of enginineering is
bridges `(Object)Unit` right back onto itself. The previous
resolution of SI-6385 (d435f72e5fb7fe) was a test case that confirmed
that we detected the zero-length bridge and reported it nicely, which
happened after related work in SI-6260. But we can simply avoid
creating in it in the first place.
That's what this commit does. It does so by reducing the amount
of information carried in `ErasedValueType` to the bare minimum needed
during the erasure -> posterasure transition.
We need to know:
1. which value class wraps the value, so we can box and unbox
as needed
2. the erasure of the underlying value, which will replace this
type in post-erasure.
This construction means that the bridge above computation now
compares:
ErasedValueType(C, Any) =:= ErasedValueType(C, Any])
I have included a test to show that:
- we don't incur any linkage or other runtime errors in the
reported case (run/t6385.scala)
- a similar case compiles when the signatures align
(pos/t6260a.scala), but does *not* compile when the just
erasures align (neg/t6260c.scala)
- polymorphic value classes continue to erase to the instantiated
type of the unbox: (run/t6260b.scala)
- other cases in SI-6260 remains unsolved and indeed unsolvable
without an overhaul of value classes: (neg/t6260b.scala)
In my travels I spotted a bug in corner case of null, asInstanceOf
and value classes, which I have described in a pending test.
|
|/
|
|
| |
for f in $(find test -name '*.check' -o -name '*.flags'); do [[ $(wc -c $f | sed -E 's/ *([0-9]+).*/\1/') == "0" ]] && rm $f; done
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
After the merge, the test/run/t7733 started to fail on Jenkins.
I tried to reproduce it locally but I couldn't so I think it's
system dependent failure. Per @retronym's suggestion I moved it to pending
to not block the whole merge.
Conflicts:
bincompat-backward.whitelist.conf
bincompat-forward.whitelist.conf
src/compiler/scala/tools/nsc/symtab/classfile/ClassfileParser.scala
src/compiler/scala/tools/nsc/typechecker/ContextErrors.scala
src/compiler/scala/tools/nsc/typechecker/Macros.scala
src/compiler/scala/tools/nsc/typechecker/Namers.scala
src/compiler/scala/tools/nsc/typechecker/NamesDefaults.scala
src/compiler/scala/tools/nsc/typechecker/RefChecks.scala
src/compiler/scala/tools/nsc/util/MsilClassPath.scala
src/compiler/scala/tools/reflect/ToolBoxFactory.scala
src/reflect/scala/reflect/internal/ClassfileConstants.scala
src/reflect/scala/reflect/internal/Importers.scala
src/reflect/scala/reflect/internal/Trees.scala
src/reflect/scala/reflect/runtime/JavaMirrors.scala
test/files/run/macro-duplicate/Impls_Macros_1.scala
test/files/run/t6392b.check
test/files/run/t7331c.check
|
| |
| |
| |
| |
| |
| |
| | |
putting in a nutshell, this patch:
* condenses some macro-XXX-a/b/c/... bundles
* renames some tests to prepare for other macro flavors
* introduces some additional tests
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
merge/v2.10.1-235-g4525e92-to-master
Conflicts:
bincompat-backward.whitelist.conf
bincompat-forward.whitelist.conf
src/compiler/scala/tools/nsc/transform/SpecializeTypes.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
src/reflect/scala/reflect/internal/Types.scala
|
| |
| |
| |
| |
| |
| | |
This reverts commit 4e10b2c833fa846c68b81e94a08d867e7de656aa.
Add 6387 test to pending and 7341 to up-to-date.
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* origin/2.10.x:
Fix for paramaccessor alias regression.
Expanded bytecode testing code.
SI-5675 Discard duplicate feature warnings at a position
accommodates pull request feedback
term and type reftrees are now reified uniformly
SI-6591 Reify and path-dependent types
SI-7096 SubstSymMap copies trees before modifying their symbols
SI-6961 no structural sharing in list serialization
SI-6187 Make partial functions re-typable
[backport] SI-6478 Fixing JavaTokenParser ident
SI-7100 Fixed infinite recursion in duplicators
SI-6146 More accurate prefixes for sealed subtypes.
SI-5082 Cycle avoidance between case companions
SI-6113 typeOf now works for type lambdas
SI-5824 Fix crashes in reify with _*
SI-7026: parseTree should never return a typed one
SI-7070 Turn restriction on companions in pkg objs into warning
Conflicts:
src/compiler/scala/reflect/reify/codegen/GenSymbols.scala
src/compiler/scala/tools/nsc/typechecker/PatternMatching.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
src/compiler/scala/tools/reflect/ToolBoxFactory.scala
src/library/scala/collection/immutable/List.scala
src/reflect/scala/reflect/internal/TreeInfo.scala
src/reflect/scala/reflect/internal/Types.scala
src/reflect/scala/reflect/internal/settings/MutableSettings.scala
src/reflect/scala/reflect/runtime/Settings.scala
test/files/buildmanager/t2650_1/t2650_1.check
test/files/buildmanager/t2657/t2657.check
test/files/neg/t3234.check
test/files/run/idempotency-this.check
test/files/run/macro-typecheck-macrosdisabled2.check
test/files/run/showraw_tree.check
test/files/run/showraw_tree_ids.check
test/files/run/showraw_tree_kinds.check
test/files/run/showraw_tree_types_ids.check
test/files/run/showraw_tree_types_typed.check
test/files/run/showraw_tree_types_untyped.check
test/files/run/showraw_tree_ultimate.check
test/files/run/t2886.check
test/files/run/t5225_2.check
test/files/run/t5374.check
test/files/run/t5374.scala
test/files/run/t6329_repl.check
test/files/run/toolbox_typecheck_macrosdisabled2.check
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Reification scheme changed. Now Select an SelectFromTypeTree trees
reified appropriately, as Select and SelectFromTypeTree accordingly.
Packages and Predef object was excluded in order not to break the
existing reification scheme and not to break tests which rely on it.
Reified free terms can contain flag <stable> to make reified values
become stable identifiers. For example in the case of
reify_newimpl_15.scala
class C {
type T
reify { val v: List[T] = List(2) }
}
class C reified as free term C$value, and List[C.T] becomes
List[C$value().T], so C$value.apply() need to pass stability test
isExprSafeToInline at scala.reflect.internal.TreeInfo. For this purpose
special case for reified free terms was added to isExprSafeToInline
function.
test run/reify_newipl_30 disabled due to SI-7082
test t6591_4 moved to pending due to SI-7083
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- `New(tpe)` doesn't survive a `resetAttrs` / typecheck; use
a name instead.
- Abandon the tree attachment that passed the default
case from `typer` to `patmat`; this tree eluded the
attribute reset performed in the macro. Instead, add it
to the match. Apart from making the tree re-typable, it
also exposes the true code structure to macros, which
is important if they need to perform other code
transformations.
- Install original trees on the declared types of the
parameters of the `applyOrElse` method to ensure that
references to them within the method pick up the correct
type parameter skolems upon retypechecking.
- Propagate `TypeTree#original` through `copyAttrs`,
which is called during tree duplication / `TreeCopiers`.
Without this, the original trees that we installed were
not visible anymore during `ResetAttrs`.
We are not able to reify partial functions yet -- the
particular sticking point is reification of the parentage
which is only available in the `ClassInfoType`.
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
build.xml
src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Reverts part of c82ecab. The parser can't assume that
a pattern `(a, b)` will match, as results of
`.isInstanceOf[Tuple2]` can't be statically known until
after the typer.
The reopens SI-1336, SI-5589 and SI-4574, in exchange for fixing
this regression SI-6968. Keeping all of those fixed will require
a better definition of irrefutability, and some acrobatics to
ensure safe passage to the ambiguous trees through typechecking.
|
| |
| |
| |
| | |
Knock on wood.
|
| |
| |
| |
| | |
For not passing on java6.
|
| | |
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* merge-wip-into-2.10.x: (44 commits)
Cleanups of reifyBoundTerm and reifyBoundType
SI-5841 reification of renamed imports
Share the empty LinkedList between first0/last0.
SI-4922 Show default in Scaladoc for generic methods.
SI-6614 Test case for fixed ArrayStack misconduct.
SI-6690 Release reference to last dequeued element.
SI-5789 Use the ReplTest framework in the test
SI-5789 Checks in the right version of the test
SI-5789 Removes assertion about implclass flag in Mixin.scala
SI-6766 Makes the -Pcontinuations:enable flag a project specific preference
more ListOfNil => Nil
DummyTree => CannotHaveAttrs
evicts assert(false) from the compiler
introduces global.pendingSuperCall
refactors handling of parent types
unifies approaches to call analysis in TreeInfo
TypeApply + Select and their type-level twins
SI-6696 removes "helper" tree factory methods
SI-6766 Create a continuations project in eclipse
Now the test suite runs MIMA for compatibility testing.
...
Conflicts:
src/compiler/scala/reflect/reify/codegen/GenUtils.scala
src/compiler/scala/tools/nsc/ast/Trees.scala
src/compiler/scala/tools/nsc/backend/icode/GenICode.scala
src/compiler/scala/tools/nsc/backend/jvm/GenASM.scala
src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
src/compiler/scala/tools/nsc/typechecker/Contexts.scala
src/compiler/scala/tools/nsc/typechecker/Namers.scala
src/compiler/scala/tools/nsc/typechecker/Typers.scala
src/eclipse/scala-compiler/.classpath
src/eclipse/scalap/.classpath
src/reflect/scala/reflect/internal/StdNames.scala
src/reflect/scala/reflect/internal/TreeInfo.scala
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As experience shows, these methods can easily be a source of confusion
for the newcomers: https://issues.scala-lang.org/browse/SI-6696.
I'm only leaving the TypeTree(tp) factory, since the facility to
set underlying types for type trees is not exposed in the public API,
as it's inherently mutable.
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* origin/2.10.0-wip:
MethodSymbol.params => MethodSymbol.paramss
SI-6471 Update jquery from 1.4.2 to 1.8.2
undeprecates manifests for 2.10.0
SI-6451: Rename classes in `unchecked-abstract.scala` test.
Put more implementation restrictions on value classes.
Fixed problem in SI-6408
Revised restrictions for value classes and unversal traits
SI-6436 Handle ambiguous string processors
fixes a bug in a weak cache in runtime reflection
Conflicts:
test/files/neg/classmanifests_new_deprecations.check
test/files/neg/unchecked-abstract.check
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Nested objects, classes and lazy vals are disallowed at any
nesting level in value classes; e.g. lazy vals local to a
method defined in a value class. There are still allowed in
universal traits.
This is a temporary, implementation restriction that is planned
to be addressed in future releases of Scala. Error messages has
been updated to communicate that intent.
Moved tests for SI-5582 and SI-6408 to pending folder. They have
to stay there until implementation restrictions are addressed.
Closes SI-6408 and SI-6432.
Review by @odersky, @harrah and @adriaanm.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the test names can be believed, this covers
SI-294 SI-1751 SI-1782 SI-2318 SI-3897
SI-4649 SI-4786 SI-5293 SI-5399 SI-5418
SI-5606 SI-5610 SI-5639
Most of these were moved to pending in 1729b26500
due to failures of unknown cause. It was suggested
they be brought back "as soon as possible" and that
was three months ago; I suppose it's now possible.
If they need to be disabled again, please move them
to test/disabled, not to test/pending. "disabled"
should mean a formerly passing test in limbo; "pending"
tests document bugs which await fixing.
I also removed some dead files in test/ - the
files with a "cmds" extension are from a failed
experiment and do not do anything.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turns importer caches into fully weak hash maps, and also applies
manual cleanup to toolboxes every time they are used.
It's not enough, because reflection-mem-typecheck test is still leaking
at a rate of ~100kb per typecheck, but it's much better than it was before.
We'll fix the rest later, after 2.10.0-final.
For more information, see https://issues.scala-lang.org/browse/SI-6412 and
http://groups.google.com/group/scala-internals/browse_thread/thread/eabcf3d406dab8b2
In comparison with https://github.com/scala/scala/commit/b403c1d,
the original commit that implemented the fix, this one doesn't crash tests.
The problem with the original commit was that it called tryFixup() before
updating the cache, leading to stack overflows.
|
|
|
|
| |
This reverts commit b403c1d7524ccdfc3455b5bc5d5363fdd9c82bec.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turns importer caches into fully weak hash maps, and also applies
manual cleanup to toolboxes every time they are used.
It's not enough, because reflection-mem-typecheck test is still leaking
at a rate of ~100kb per typecheck, but it's much better than it was before.
We'll fix the rest later, after 2.10.0-final.
For more information, see https://issues.scala-lang.org/browse/SI-6412 and
http://groups.google.com/group/scala-internals/browse_thread/thread/eabcf3d406dab8b2
|
|
|
|
|
|
| |
This brings all the files into line with the .gitattributes
settings, which should henceforth be automatically maintained
by git.
|
|
|
|
|
|
|
|
|
|
| |
Previously tb.typeCheck used default typer, which builds upon NoContext.
Changing the context to analyzer.rootContext(NoCompilationUnit, EmptyTree)
fixed the missing imports problem.
Unfortunately this doesn't help in cases like "math.sqrt(4.0)" because of
https://issues.scala-lang.org/browse/SI-6393. But anyways I'm adding
this test case to pending.
|
|
|
|
|
|
| |
1) parseExpr => parse
2) runExpr => eval
3) Introduces compile(Tree): () => Any, since it has frequent uses
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new name for AbsTypeTag was a matter of a lengthy discussion:
http://groups.google.com/group/scala-internals/browse_thread/thread/fb2007e61b505c4d
I couldn't decide until having fixed SI-6323 today, which is about
trying to reflect against a local class using typeOf.
The problem with local classes is that they aren't pickled, so their metadata
isn't preserved between Scala compilation runs. Sure, we can restore some of
that metadata with Java reflection, but you get the idea.
Before today typeOf of a local class created a free type, a synthetic symbol,
with a bunch of synthetic children that remember the metadata, effectively
creating a mini symbol table. That might be useful at time, but the problem is
that this free type cannot be reflected, because the global symbol table of
Scala reflection doesn't know about its mini symbol table.
And then it struck me. It's not the presence of abs types (type parameters and
abs type members) that differentiates arbitrary type tags from good type tags.
It's the presence of types that don't map well on the runtime world - ones that
can't be used to instantiate values, ones that can't be reflected.
So we just need a name for these types. Phantom types are compile-time only
concept, whereas our types can have partial correspondence with the runtime.
"Weak types" sound more or less okish, so let's try them out.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original idea was to support both both TypeTags and ConcreteTypeTags as
context bounds on macro implementations.
Back then TypeTags were the implied default flavor of type tags. Basically
because "TypeTag" is shorter than "ConcreteTypeTag" everyone jumped onto
them and used them everywhere.
That led to problems, because at that time TypeTags could reify unresolved type
parameters ("unresolved" = not having TypeTag annotations for them). This
led to a series of creepy errors, when one forgets to add a context bound
in the middle of a chain of methods that all pass a type tag around, and then
suddenly all the tags turn into pumpkins (because that unlucky method just
reifies TypeRef(NoPrefix, <type parameter symbol>, Nil and passes it down
the chain).
Hence we decided to rename ConcreteTypeTag => TypeTag & TypeTag => AbsTypeTag,
which makes a lot of sense from a reflection point of view.
Unfortunately this broke macros (in a sense), because now everyone writes
TypeTag context bounds on macro implementations, which breaks in trivial
situations like: "def foo[T](x: T) = identity_macro(x)" (the type of x
is not concrete, so macro expansion will emit an error when trying to
materialize the corresponding TypeTag).
Now we restore the broken balance by banning TypeTag from macro impls.
This forces anyone to use AbsTypeTags, and if someone wants to check the input
for presence of abstract types, it's possible to do that manually.
|
|
|
|
| |
Removes the stubs left out to appease the old starr, fixes macro tests.
|
|
|
|
|
|
| |
Added all the known cases of failing self-types. Added tests for symbol
access (SI-4601) as well which should now be fixed for all of the same cases
as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently there are discrepancies between the behavior of
c.reify and c.universe.reify.
First step in fixing these problems is removing the duplication in the API.
That's why I'm cutting away the Context.reify shortcut.
Context.reify is a magic macro, hardwired in the fast track mechanism, so
removing it requires redeploying the starr (because an old starr will
crash if launched on sources that don't contain Context.reify).
To cleanly redeploy a starr I've left a Context.reify stub in sources,
but hidden it behind a `protected` modifier. When starr is redeployed
(in a subsequent commit) the stub will be removed.
I've also updated the tests to use c.universe.reify instead of c.reify.
This will break some of them, because c.universe.reify uses a standard
compiler mirror, which unlike a macro mirror doesn't like packageless classes.
That's an annoyance, but I think having clean separation of commits
is more important that being 100% consistent.
|
|\
| |
| | |
SI-5695 removes Context.enclosingApplication
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Apparently it's impossible to find out the enclosing Apply node
if you're an argument being typechecked (because the arguments
are typechecked separately from the enclosing Apply).
This functionality is by far not a core feature of macros,
so I'm removing it.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have this sneaky suspicion that part of these spurious failures
are caused by the recent partest optimizations.
@axel22 already checked that compiler instances are not shared between test runs.
However, except for the benchmark test, they all have a distinct
race condition in symbol loading/type checking feel to them.
Since, in the end, the tests and/or their corresponding fixes are as likely
a culprit as the test framework, moving them out of the way until their owners
can get them back in line and they stop throwing primate wenches into our build.
We should bring them back as soon as possible, though.
|
|
|
|
|
| |
this uncovers a bug in toolboxes: https://issues.scala-lang.org/browse/SI-6007
however that bug is not critical, so it will be dealt with later
|