| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Test a wider range of functionality.
|
| |
|
|
|
| |
No need to check the output - checking programmatically that the
produced streams are empty is enough.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The included test currently fails because `map` and `flatMap` do not
run in constant stack space on a stream returned by `Stream.withFilter`,
as I reported here:
https://groups.google.com/d/msg/scala-language/WqJR38REXnk/saaSiDdmyqoJ
Fix the problem and add a simple testcase.
Note that the stack space consumed when producing an element of this stream is
proportional to the number of elements failing the test before the next
success. The stack space consumed to produce the stream itself is the
space needed to produce the first element, that is, is proportional to
the number of failures before the first success.
|
| |\
| |
| | |
more cleanup in Macros.scala
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
In separate compilation runs, the static field symbol in the
companion class of an object was not being recreated.
Given that the singleton object was compiled separately,
the static field symbol will be recreated on demand.
|
| |/
|
|
|
|
|
|
| |
Disable @static for the REPL code.
The problem is that there are no companion classes generated for objects
that contain the top-level declarations in the REPL.
When there is no companion class, the selecting a @static field will translate
to a getter call, instead of to a field load.
|
| |\
| |
| | |
Fixes backend crash due to incorrect consumedTypes
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This started out as a compiler crash after Greg copied the
comprehension methods to List and made them final.
The culprit was the dead code elimination phase, which after
sweeping pieces of code was unable to restore the stack to its
original state, thus causing the ASM backend to crash notifying
the resulting bytecode is incorrect.
The dead code elimination phase uses the icode Instructions'
consumedTypes to determine what needs to be dropped from the
stack when an instruction is eliminated, but the consumedTypes
were only defined for a handful of instructions. So dce encountered
a DUP instruction for which it did not have consumedTypes defined
and did not restore the stack correctly.
The consumedTypes/producedTypes for icode instructions are
redundantly defined in 3 separate places:
- Opcodes.scala (consumedTypes/producedTypes)
- ICodeCheckers.scala (for checking icode)
- TypeFlowAnalysis.scala (for computing types on the stack at each
program point)
Since the Opcodes types are the only ones visible outside, I suggest
we use them in ICodeCheckers.scala and TypeFlowAnalysis.scala too. But
we should make such changes after the release, as we're chilling out
by the lake with a glass of good wine: SI-6234
The relevant discussion around it can be found at:
https://groups.google.com/forum/?fromgroups#!topic/scala-internals/qcyTjk8euUI[1-25]
Many thanks to Paul for his help!
Review by @magarciaEPFL or @paulp.
|
| |/
|
|
|
|
| |
mostly removes [Eugene] marks that I left back then and reviews related code
some of those tokens got left in place, because I don't know to how fix them
without imposing risks on 2.10.0
|
| |\
| |
| | |
SI-5940 impls are no longer in macro def pickles
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The first officially released version of macros persisted
macro def -> impl bindings across compilation runs using a neat trick.
The right-hand side of macro definition (which contains a reference to an impl)
was typechecked and then put verbatim into an annotation on macro definition.
This solution is very simple, but unfortunately it's also lacking. If we use it
then signatures of macro defs become transitively dependent on scala-reflect.jar
(because they refer to macro impls, and macro impls refer to
scala.reflect.macros.Context defined in scala-reflect.jar).
More details can be found in https://issues.scala-lang.org/browse/SI-5940.
Therefore we have to avoid putting macro impls into binding pickles and
come up with our own serialization format. Situation is further complicated
by the fact that it's not enough to just pickle impl's class and method names,
because macro expansion needs knowledge about the shape of impl's signature
(which we can't pickle). Hence we precompute necessary stuff (e.g. the layout
of type parameters) when compiling macro defs.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This change fixes a situation in which method calls aren't being properly
specialized. All the existing tests pass; in addition, it likely fixes other
specialization bugs (and improves performance of specialized code).
Also includes a small regression test.
|
| |\ \
| | |
| | | |
Only create a HashTrieSet if necessary.
|
| | | |
| | |
| | |
| | | |
yields a HashSet1 as it should
|
| |\ \ \
| |_|/
|/| | |
Si 6198
|
| | |/
| |
| |
| | |
This tests that ListSet.tail is O(1) as well as testing that a HashSetCollision1 is turned back into a HashSet1 when removing all but one element
|
| |\ \
| | |
| | | |
SI-5739 (bis) vals for subpatterns when -g:patmatvars
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
To facilitate debugging pattern matches, we store the values for
sub-patterns of extractor (synthetic or user-defined) patterns in local variables.
When performing an optimized build, and when possible, we don't do store but inline them directly.
For soundness, SI-5158, SI-6070, we must always store the values of mutable case class fields.
(Specifying -optimize is the only way to suppress emitting these local variables.
An unoptimized build will always generate them, which was deemed the right default during the meeting.)
(updated flags for t4425 to get consistent runs on optimized and non-optimized partest runs
by always passing -optimize)
|
| |\ \ \
| | | |
| | | | |
reflection now correctly supports inner classes and modules
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Our name mangling scheme w.r.t stuff nested into objects conflicts
with JVM's ideas of beauty, which messes up getDeclaredClasses.
Scala reflection needs getDeclaredClasses to convert between Scala and Java,
so the situation looked grim. Greg suggested a workaround described in:
https://issues.scala-lang.org/browse/SI-4023?focusedCommentId=54759#comment-54759.
Luckily the workaround worked!
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
As per referenced issue, this patch implements `instance`
for ModuleMirrors corresponding to nested and inner modules.
|
| |\ \ \ \
| |_|/ /
|/| | | |
SI-6040 error on unauthorized extension Dynamic
|
| | | | |
| | | |
| | | |
| | | | |
authorization is easy to get: `import language.dynamics`
|
| |\ \ \ \
| |_|_|/
|/| | | |
SI-6186 TypeTags no longer supported in macros
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 AnyRef specialization from library
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As discussed in #999, #1025 and
https://groups.google.com/forum/?hl=en&fromgroups#!topic/scala-internals/5P5TS9ZWe_w
instrumented.jar is generated from the current source, there's no need
for a bootstrap commit.
Review by @paulp.
|
| |\ \ \
| |/ /
|/| | |
Ultimate reflection pull request #2
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since Scala reflection relies on Java reflection to perform member invocations,
it inherits some of the quirks of the underlying platform.
One of such quirks is returning null when invoking a void-returning method.
This is now fixed by introducing a check after calling invoke.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously `checkMemberOf` was blocking base fields and methods
that are overriden in receiver.getClass. Now this is fixed.
The fix also uncovered an issue with field mirrors. Currently
their `get` and `set` methods don't respect overriding and always
return field values from a base class.
After discussing this on a reflection meeting, we decided that this
behavior is desirable and that for overriding people should use
reflectMethod and then apply on getters/setters. See the discussion at:
https://github.com/scala/scala/pull/1054.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In 911bbc4 I've completely overlooked the fact that
reflectConstructor exists and that is also needs sanity checks.
Now reflectConstructor checks that the incoming symbol is actually a ctor,
and that it is actually a ctor of the class reflected by the current mirror.
|
| | | |
| | |
| | |
| | |
| | | |
Arguments provided in by-name positions are now automatically wrapped
in Function0 instances by method mirrors.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
mirrors now carry a class tag of the receiver, so that they can detect
value classes being reflected upon and adjust accordingly (e.g. allow
Int_+ for ints, but disallow it for Integers).
Surprisingly enough derived value classes (SIP-15 guys that inherit from AnyVal)
have been working all along, so no modification were required to fix them.
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In Scala there are some methods that only exist in symbol tables,
but don't have corresponding method entries in Java class files.
To the best of my knowledge, these methods can be subdivided into five groups:
1) stuff weaved onto Any, AnyVal and AnyRef (aka Object),
2) magic methods that Scala exposes to fix Java arrays,
3) magic methods declared on Scala primitive value classes,
4) compile-time methods (such as classOf and all kinds of macros),
5) miscellaneous stuff (currently only String_+).
To support these magic symbols, I've modified the `checkMemberOf` validator
to special case Any/AnyVal/AnyRef methods and adjusted MethodMirror and
ConstructorMirror classes to use special invokers for those instead of
relying on Java reflection.
Support for value classes will arrive in the subsequent commit, because
it requires some unrelated changes to the mirror API (currently mirrors
only support AnyRefs as their targets).
|
| |\ \
| | |
| | | |
SI-6063, SI-4945 and restore :warnings in the REPL
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As seen here.
scala> class A { @deprecated("foo") def a = 1 }
warning: there were 1 deprecation warnings; re-run with -deprecation for details
defined class A
scala> :warnings
<console>:7: warning: @deprecated now takes two arguments; see the scaladoc.
class A { @deprecated("foo") def a = 1 }
^
scala> val x = 5 toString
warning: there were 1 feature warnings; re-run with -feature for details
x: String = 5
scala> :warnings
<console>:7: warning: postfix operator toString should be enabled
by making the implicit value language.postfixOps visible.
This can be achieved by adding the import clause 'import language.postfixOps'
or by setting the compiler option -language:postfixOps.
See the Scala docs for value scala.language.postfixOps for a discussion
why the feature should be explicitly enabled.
val x = 5 toString
^
|
| | |/
| |
| |
| | |
Have to rule out access boundaries as well as private/protected.
|
| |\ \
| |/
|/| |
SI-6102 Wrong bytecode in lazyval + no-op finally clause
|
| | | |
|
| |\ \
| |/
|/| |
SI-6188
|
| | | |
|
| | | |
|
| |\ \
| |/
|/| |
SI-6175 reflect over classes with symbolic names
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Top-level classes with symbolic names (having binary names like $colon$colon)
have previously been incorrectly treated as local classes by Scala reflection.
As a result they were loaded as if they weren't pickled (i.e. as Java classes).
Moreover this bug also had a more subtle, but more dangerous manifestation.
If such a class has already been loaded indirectly by unpickling another class
(which refers to it in its pickle) and then someone tried to load it explicitly
via classToScala, then it would be loaded twice (once as a Scala artifact and
once as a Java artifact). This is a short route to ambiguities and crashes.
The fix first checks whether a class with a suspicious name (having dollars)
can be loaded as a Scala artifact (by looking it up in a symbol table).
If this fails, the class is then loaded in Java style (as it was done before).
Ambiguous names that can be interpreted both ways (e.g. foo_$colon$colon)
are first resolved as Scala and then as Java. This prioritization cannot lead
to errors, because Scala and Java artifacts with the same name cannot coexist,
therefore loading a Scala artifact won't shadow a homonymous Java artifact.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of trying to serialize the entire universe and failing miserably
(which happens now), exprs and type tags will now serialize their creators
and deserialize into scala.reflect.basis.
Since creators produced by reification are not serializable right now,
serialization will crash. That's a small improvement over state of the art
functionality-wise, but it's a step forward robustness-wise.
Next step in this direction is generation of serialization code for creators.
Related issues: SI-5919 and SI-5908. Also see the discussion at scala-internals
http://groups.google.com/group/scala-internals/browse_thread/thread/ef63f8b5bd194c7c
|
| |
|
|
| |
Removes the stubs left out to appease the old starr, fixes macro tests.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added a bunch of test methods to symbols to cover public flags:
(e.g. isPrivate, isFinal, isOverride, isImplicit, etc). I'd argue that
the API duplication w.r.t flag sets is trumped by unified interface
to tests and better encapsulation.
Also updated the API to be easier to understand after prior exposure
to Java or .NET reflection APIs:
1) Added typeParams to TypeSymbol and ClassSymbol.
2) Renamed MethodSymbol.resultType to returnType.
3) Removed the distinction between MethodSymbol.params vs MethodSymbol.allParams
now we just have MethodSymbol.params: List[List[Symbol]].
|
| |
|
|
|
|
|
|
| |
Adds informative toString for InstanceMirror, FieldMirror,
MethodMirror (for methods and constructors), ClassMirror and ModuleMirror.
Universe mirrors (e.g. JavaMirrors or compiler mirrors) already have good
toString methods that show their affiliation and/or classpaths.
|
