| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|\
| |
| | |
Multiple fixes to @static
|
| | |
|
|\ \
| | |
| | | |
Fix issue with GADT not typechecking without bind in match
|
| | | |
|
| |/ |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
| |
If directly applicable alternatives exists, do not try other
alternatives. The original motivation for this change was to reduce the
number of searches for implicit views we do since some overloaded
methods like `Int#+` are used a lot, but it turns out that this also
makes more code compile (see `overload_directly_applicable.scala` for an
example), this change does not seem to match what the specification
says (it does not define a notion of "directly applicable") but it does
match the behavior of scalac, and it seems useful in general.
|
| |
|
|
|
|
| |
This reduces the number of implicit scopes we cache.
|
|
|
|
|
|
| |
Many intermediate `OfTypeImplicits` are created during a call to
`implicitScope`, but they won't all be used so there is no need to
compute `OfTypeImplicits#refs` unless it's actually used.
|
|
|
|
|
| |
This did not work before because we incorrectly looked for their value
in the prefix of the type instead of the type itself.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue is subtle: the `tp` in scope in `def ofTypeImplicits` is the
`tp` passed to the top-level `implicitScope` method, not the `tp` passed
to the recursively called `iscope`, this means that before this commit,
all intermediate `OfTypeImplicit` scopes cached while computing an
implicit scope had their `tp` field incorrectly set, which means that we
could miss implicits in later implicit searches.
Note that the `implicit_cache.scala` test worked before this commit
because of the restrictions on caching that exist since
b8b0f381ef2cbcb7bad66fd3e7a9ae929baa45f6, it is included anyway because
our caching strategy might change in the future.
|
| |
|
| |
|
|
|
|
|
|
|
| |
One drawback with this approach is that the type seems to propagate.
I.e. if the return type of an expression is `repeated` then the
enclosing variable will get the `repeated` type instead of getting the
expected `Seq` type
|
| |
|
|\
| |
| | |
Fix bootstrap
|
| |
| |
| |
| |
| |
| |
| | |
Do this in the inferred (result-)type of ValDefs and DefDefs.
Without this fix, TreeTraverser#traverseChildren in Trees.scala
gets a result type of BoxedUnit (but only when co-compiled from
source, not when unpickled).
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To make tests pass, this required a looser specification of
`assumedCanEquals`, so that an abstract type T can be compared to
arbitrary values, as long as its upper bound can be compared. E.g.
T == null
T == "abc"
|
| | |
|
| |
| |
| |
| |
| | |
Needed a fix in string interpolation for suriviving inserted
types that contain `$` characters.
|
| | |
|
| |
| |
| |
| |
| |
| | |
This is done by checking each instance of an eqAny implicit
so that it does not contain non-bottom instances of equality
types as instances.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also, check that pattern matching against idents/selects/literals makes
sense.
The hooks perform an implicit search for an instance of `Eq[L, R]`, where
`L`, `R` are the argument types. So far this always succeeeds because Eq.eqAny
matches all such types. A separate commit will check the returned
search term for validity.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Compare selected contravariant arguments as if they were covariant.
Which ones is explained in the doc comment for method `isAsSpecificValueType`
in Applications.scala.
This has the same motivation than what @paulp proposed around 2012. The solution is a bit
different from the one proposed then because it only affects top-level parameters.
|
| |
| |
| |
| |
| |
| | |
Caches were set when information was not complete yet. Problem was
exhibited by missing some `eqName` implicits when adding safe equality
for Name.
|
| |
| |
| |
| |
| |
| |
| |
| | |
If all overloaded variants of a method are uniary, we should
also allow auto-tupling. This is necessary to make overloaded
`==' methods work in cases like:
xs == (1, 2)
|
|\ \
| |/
|/| |
Evaluate annotations before completing tree of definitions
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Motive: That way we can identify annotation macros without special
name resolution rules.
This was surprisingly easy.
|
| |
| |
| |
| |
| | |
Used to throw an uncaught merge error in checkAllOverrides
when compiling i1240c.scala.
|
| |
| |
| |
| |
| |
| |
| | |
This happens once we do not merge methods with the same signature coming
from the same class. (reverted from commit 83262d090a98e2374c9b3e5a1480892397d695d3)
This case no longer applies as such a situation will now give a MergeError instead.
|
|/
|
|
|
| |
This happens once we do not merge methods with the same signature coming
from the same class.
|
| |
|
| |
|
|
|
|
|
| |
No longer needed because we are going to allow dependent method types
in extractors, and the unary requirement is kind of obvious.
|
|
|
|
|
| |
Now explains in detail why an possibly found unapply or
unapplySeq is ineligible.
|
|
|
|
|
|
|
|
|
|
| |
There's a trap otherwise that, when in a class inheriting
from Context (and with it Reporting) a call to println will
go to this.println and therefore might not print at all, if
the current context buffers messages. I lost a lot of time
on this on several occasions when I scratched my head why
a simple debug println would not show. Better avoid this in
the future for myself and others.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When an implicit argument is not found, we should in any case
assume the result type of the implicit method as the type of
the tree (after reporting an error, of course). If we don't
do that, we get implicit errors on weird positions when we try
to find an implicit argument for the same tree again. This
caused a spurious error in subtyping.scala, and also caused
an additional error at the end of EqualityStrawman1.scala.
|
|
|
|
|
|
| |
implicit.
This was suggested in #878.
|
| |
|
|
|
|
|
|
| |
This allowed to simplify the code in both Applications and tpd.newArray.
Now, only creation of generic arrays is handled by typer.
All other arrays are handled in ArrayConstructors phase.
|
|
|
|
|
| |
It's needed in order to create calls to newGenricArray
as it needs to infer the ClassTag.
|
|
|
|
| |
It's done in a separate ArrayConstructors phase now.
|