| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This brings all the files into line with the .gitattributes
settings, which should henceforth be automatically maintained
by git.
|
|
|
|
|
| |
As the experience has shown, there's no need for a separate layer of reflection
in scala-library.jar. Therefore I'm putting an end to it.
|
|
|
|
|
|
|
|
| |
This reverts commit cb393fcbe35d0a871f23189d791b44be1b826ed2.
Conflicts:
src/compiler/scala/tools/nsc/backend/icode/GenICode.scala
|
|\
| |
| | |
cleaning up reflection
|
| |
| |
| |
| |
| |
| | |
1) parseExpr => parse
2) runExpr => eval
3) Introduces compile(Tree): () => Any, since it has frequent uses
|
|\ \
| |/
|/| |
Fix for SI-6245 with workaround for SI-2296.
|
| |
| |
| |
| |
| |
| |
| | |
protected/super accessor issue: Don't subvert the creation of the
standard protected accessor with the java interop accessor. For
SI-2296, the compiler emits an error instead of causing an illegal
access error at runtime.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
|
|
|
| |
This works around the issue of the inability to use classOf for top-level object classes by inventing a new
anonymous class and instantiating it just to grab its class. Since the class is a nested type of the
top-level object it'll be in the same classloader unless some kind of evil behavior is afoot.
This patch should be undone if ever SI-2453 ever gets fixed, or we wind up with a direct way to grab
the class of an object.
|
|\
| |
| | |
Fix for SI-6367, exponential time in inference.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This pathology is not new - it can be witnessed in 2.9,
where compiling the test case enclosed with this ticket with
-Yinfer-debug will print a line with (pinky to lips) one million
type parameters. 1048576 actually, aka 2^20. But in 2.9 we were
somehow getting away with creating the list, presumably by not
spending much time looking at it. Somewhere between there and M1,
that changed.
I cut it off at the knees - don't create a list of one million
upper bound constraints when 1 will suffice. It would not be too
surprising if this proves to be a boon for performance.
|
|/ |
|
|
|
|
| |
it keeps failing randomly, e.g. http://scala-webapps.epfl.ch/artifacts/e3b0c7abbf637dacce7bcd7b69d5655820e8e714/buildLog.txt
|
|\
| |
| | |
SI-6335 More precise location of the implicit class synthetic method.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
One approach would be to disallow an implicit class in a template
that already has a member with the same name.
But this commit doesn't do this; instead it uses `isSynthetic` to
find the synthesized implicit conversion method from the potentially
overloaded alternatives.
|
|/
|
|
|
|
|
|
|
| |
class
Add a case to the ad-hoc (or add-hack) addSynthetics to keep the trees close.
This relies on naming convention, so changes in naming of the implicit def
would require an update here.
|
|\
| |
| | |
SI-6274 Fix owners when eta-expanding function with byName param
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When eta-expanding a function that takes a by-name param the local definition
for the corresponding argument is a function-0
val eta$1 = () => { argument-to-by-name }
If there are any definitinos in the `argument-to-by-name`, the symbol
owner needs to be changed to the anonymous function's symbol.
To know the function symbol in eta expand, we need to type-check the
function, and therefore pass the `Typer` instance to `etaExpand`.
|
|\ \
| |/
|/| |
Fix SI-6294.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
My summary in the ticket was incorrect. The problem was that the
class type parameters were being cloned for the method and being
allowed to keep their variance. I threw in an assertion for anyone
attempting to create a method type with variant type parameters,
because hey, why should we allow such madness.
|
|/ |
|
|\
| |
| | |
JavaConversions: Restore source compatibility with 2.9
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Even after the parent change, implicit conversions should still convert
ConcurrentHashMap to concurrent.Map and not to mutable.ConcurrentMap.
I'll include the comment by axel22 which prompting this change (taken
from https://github.com/scala/scala/pull/1172#issuecomment-7928285)
since it is highly informative and links to pull request comments might
not be very stable:
<<
Instead of just testing an implicit conversion to ConcurrentMap, the
test should call ConcurrentMap methods such as putIfAbsent (which
returns an Option[T]) and replace, to see if the correct Scala
concurrent map trait is being resolved.
The problem is that putIfAbsent already exists on juc.ConcurrentMap so
instead of triggering an implicit conversion, a type mismatch error is
output anyway.
And we cannot test that the correct concurrent map trait is returned
using methods like map, flatMap and friends, because concurrent map
traits extends mutable.Map anyway.
For this reason, I recommend to add this to the test:
scala> val a = new java.util.concurrent.ConcurrentHashMap[String,
String]() += (("", ""))
a: scala.collection.concurrent.Map[String,String] = Map("" -> "")
and make sure that the returned map is concurrent.Map, not
mutable.ConcurrentMap (the above += is one of the few methods in
collection that has the return type this.type).
>>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Readd an implicit conversion which was available in 2.9, the one from
`java.util.concurrent.ConcurrentMap` (`juc.ConcurrentMap`) to the (now
deprecated) type `scala.collection.mutable.ConcurrentMap`.
This implicit conversion can also be used to convert from
`juc.ConcurrentMap`
to `collection.Map` and creates an ambiguity error in
test/files/run/map_java_conversions.scala. To fix this, I have given
lower priority to the new conversion.
Moreover, update the documentation in `JavaConversions`: mark this
conversion as deprecated and mention the new conversion which replaces
it, converting to `scala.collection.concurrent.Map`.
I discussed this issue previously with Paul Phillips on scala-language:
https://groups.google.com/d/topic/scala-language/uXKRiGXb-44/discussion
|
|/
|
|
|
|
|
|
|
|
|
|
| |
It turns out that exists is not inlinable, even if put into List.
We try to eliminate or hoist most closures passed to exists in Types.
There are some other small improvements as well.
--
(@gkossakowski): This commit contains also a fix to crasher
prepared by @paulp. I squashed that commit and kept the
test-case that came with it.
|
|\
| |
| | |
Fix for community build blocker.
|
| |
| |
| |
| |
| |
| |
| |
| | |
As two character bugfixes go, this was a doozy.
I will forego elaborating at length and offer generic
instructions for elucidation:
% git log --grep=tpeHK
|
|/
|
|
|
|
| |
Previously I thought it's fixed because I didn't include the correct
testcase. Now it's the correct testcase and this prompted me to
change the code a bit to make it work properly.
|
|\
| |
| | |
Fix SI-6208. mutable.Queue now returns mutable.Queue for collection met...
|
| |
| |
| |
| | |
rather than MutableList.
|
|\ \
| | |
| | | |
SI-6022 cleaner model of variable equality modulo <:
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
a more conservative "excludes": no need to reason about types
(TODO: check we don't get any spurious unreachability errors
in the eclipse build, which is a good canary for this kind of thing)
|
|\ \ \
| | | |
| | | | |
Ticket 6184 revised
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | | |
this should fix the crash in asSeenFrom that resulted from calling
baseTypeSeq on a type that had an unbound type parameter in it
also, simplify widenToClass
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes several oversights that led to 6201. RootPackage should have been static,
refactored implementation of hasSymbolWhich shouldn't have checked hasSymbol.
Full discussion is here:
http://groups.google.com/group/scala-internals/browse_thread/thread/9500348f273a8aa.
|
|\ \ \
| | | |
| | | | |
fixes to existential-related reification problems
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When reifying certain trees/types reifier might decide that it needs to
introduce auxiliary symbols to represent non-locatable components of types
For example, when reifying a refined type we need to reify the symbols
that correspond to its members (aka RefinedType.decls). Since these symbols
are not stored in pickles, we can't do the usual staticClass(scala.Int) stuff,
and are forced to actually create corresponding symbols inside the reificode
(by "create" I mean literally create, by using newXXXSymbol methods).
It looks like a generally good idea to not only create those symbols naked,
but to also export their type signatures and annotations. However this brings
problems with type inference.
Say, a type of a method A depends on a type tag. To get a type of a type tag,
the compiler needs to expand the corresponding macro (when the macro is being
expanded, symbol A is marked as LOCKED). While reification macro expands,
it might want to reify certain symbol definitions (as explained above). If one
of these definitions is a class that contains method A, we're in trouble,
since reifying the corresponding ClassInfoType will eventually call A.info,
which will produce a cyclic reference error, because A is LOCKED.
An obvious solution is to check whether a reified symbol definition is locked.
If the symbol is locked, then the reifier bails (e.g. by reifying NoType
instead of the actual type signature of the symbol).
Being obvious this solution is also incorrect as illustrated by SI-6204.
Sure we can check whether a symbol itself is locked, but we cannot check
whether or not we reify someone who refers to the locked symbol.
As of such I'm telling the reifier to bail whenever it needs to reify a symbol
definition for a symbol that is not yet complete. Therefore reification
can no longer cause inference of method result types, which eliminates the
underlying problem.
This is a harsh measure, but taking into account that we have an RC planned
within a week, stability trumps completeness.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Unlike module classes that are going to be pickled (which are reified
as `<their module reification>.moduleClass), module classes of
local modules need to be reified as symbol defs.
Otherwise we get a stack overflow:
1) Local modules are deemed to be free terms,
2) All free symbols are reified together with their type signature (so that they
can be a) inspected by anyone interested, b) compiled at runtime),
3) Reifying a type signature of a module involves reifying its module class,
4) Reifying a module class involves reifying a module and calling its module class,
<ad infinitum>
This stack overflow doesn't happen for locatable modules, because they don't need
to have their type signatures reified (these signatures can later be loaded from
pickles if it becomes necessary).
|
|\ \ \ \
| |_|/ /
|/| | | |
Moved inline logic before pickler.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The test case failed due to separate compilation. The problem was
that we don't pickle the fact that the field was made public.
Original patch by @odersky. Cleaned up by me. Changes I made:
* removed stale test-case
* reduced whitespace changes
Supersedes #1089.
Review by @odersky and @moors.
|
|\ \ \ \
| | | | |
| | | | | |
SI-6205 make pt fully defined before inferTypedPattern
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
refines my fix for SI-2038 (#981) by making pt fully defined before calling inferTypedPattern,
instead of making the result of inferTypedPattern fully defined
I finally realized my mistake by diffing the -Ytyper-debug output of compiling the variants with:
```
x match {case Holder(k: A[kt]) => (k: A[kt])}
```
and
```
(x: Any) match {case Holder(k: A[kt]) => (k: A[kt])}
```
|
|\ \ \ \
| |/ / /
|/| | | |
SI-6145 lax typing of args to synthetic case-labels
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use wildcard for the expected type of the arguments of a jump to a label
synthesized by the pattern matcher... except during erasure: we must take the
expected type into account as it drives the insertion of casts!
It's ok since we're typing the translation of well-typed code. The only "type
errors" we catch are skolem mismatches. (after erasure the existential types that
before caused problems have disappeared.)
It's necessary to balance GADT magic, SI-6145, CPS type-driven transforms and
other existential trickiness. I've exhausted all other semi-clean approaches I
could think of:
- the right thing to do -- packing existential types -- runs into limitations
in subtyping existential types,
- casting breaks SI-6145 (and it's an unnecessary cast at run time),
- not casting breaks GADT typing as it requires sneaking ill-typed trees
past typer
|
|\ \ \
| | | |
| | | | |
SI-6040 error on unauthorized extension Dynamic
|
| | | |
| | | |
| | | |
| | | | |
authorization is easy to get: `import language.dynamics`
|
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|\ \ \
| |/ /
|/| | |
SI-5788 Tailcalls LabelDefs correctly duplicated
|