| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
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
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
... in specialization.
This is a quick hack to get SI-5788 fixed in 2.10.x. The full patch,
which fixes the tailcalls LabelDefs will be merged into trunk, as it's
too late for big changes.
For reference, the complete fix is: e86afe65c8
|
| |/ |
|
| |\
| |
| | |
Fix for SI-6084, type alias crasher.
|
| | |
| |
| |
| |
| |
| | |
"no need for pt.normalize here, is done in erasure"
ORLY? Review by @adriaanm.
|
| |\ \
| | |
| | | |
SI-5930 SI-5897 reduce redundant warnings in matches, fix flags usage
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
the pattern matching analysis should be more precise anyway
(don't warn twice)
|
| | | |
| | |
| | |
| | | |
Removes the stubs left out to appease the old starr, fixes macro tests.
|
| |\ \ \
| | | |
| | | | |
Fixed SI-5031. Only consider classes when looking for companion class.
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
sym.effectiveOwner revealed this piece of inconsistency. companionModule
is fine because similar check is there already.
Review by @paulp.
|
| |\ \ \
| |/ /
|/| | |
SI-2038 make pt fully-defined when typing Typed
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
dropExistential turns existentials in the expected type (pt) that's passed to `typed`
into `BoundedWildcardType`s, but those should not end up in trees
when typing a `Typed` node, we didn't check for the type being fully defined (`isFullyDefined`)
(and thus did not make it fully defined by turning these BWTs into existentials again using `makeFullyDefined`)
|
| |\ \ \
| | | |
| | | | |
SI-6142: warn @inline-methods ending up not inlined (rightfully or not)
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | | |
SI-5958 This deserves a stable type
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
`this` (or the self variable) passed as an actual argument to a method
should receive a singleton type when computing the method's resultType
this is necessary if the method's type depends on that argument
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
... in a less nice way than I would like. Essentially, we mask type errors at later stages that arise from comparing existentials and skolems because we know that they are not tracked correctly through all tree transformations. Never mind that all these types are going erased anyway shortly afterwards. It does not smell nice. But as I write in the comment, maybe the best way out is to
avoid skolems altogether. Such a change by far exceeds the scope of this pull request however.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Don't warn on "uncheckable" type patterns if they can be
statically guaranteed, regardless of their runtime checkability.
This covers patterns like Seq[Any] and lots more.
Review by @adriaanm.
|
| |\ \ \
| |_|/
|/| | |
SI-6117 regression involving import ambiguity.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Today I learned that
foo.member("bar") != foo.member("bar")
if bar is overloaded, because each lookup of an overloaded member
creates a new symbol (with equivalent OverloadedTypes.) How should symbols
be compared so these do not appear unequal? Is there a method which
unpacks the alternatives and compares them individually? It seems likely
there are additional bugs which arise from not covering this case.
Since this bug is in the context of importing, if the prefixes are
identical then I can compare the names instead of the symbols and this
issue goes away. But for the rest of the time during which one might
encounter overloaded symbols, that would be a very lossy operation,
since the overloaded symbol might be encoding any subset of the members
with that name.
There are lots of references to "OverloadedSymbol" in the comments of
various methods in Types, but no such class is visible in the history.
If we had such a thing, we could refine its equals method to recognize
equivalent overloads.
Review by @odersky.
|
| |\ \ \
| |_|/
|/| | |
Improve unchecked warnings.
|
| | | |
| | |
| | |
| | |
| | | |
Spurious test was not good. Better test avoids suppressing
some legitimate warnings. Review by @moors.
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
Changed behavior so that when determining the target variance of a method parameter,
the variance in formals comes first. If variance is still undecided by that,
the variance in the result type is used as a secondary criterion.
(This is also done when determining prototype type params.)
|
