| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Add "enum" construct
|
| | |
|
| |
| |
| |
| |
| |
| | |
Infer type arguments for enum paraments from corresponding type
parameter bounds. This only works if the type parameter in question
is variant and its bound is ground.
|
| |
| |
| |
| |
| | |
Previous expansion caused 3 spurious follow-on errors which are now
avoided.
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
| |
`checkNoPrivateLeaks` can force a lot of things, this lead to
hard-to-reproduce issues in unpickling because we called
`checkNoPrivateLeaks` on the type parameters of a class before anything
in the class was indexed. We fix this by making sure that
`checkNoPrivateLeaks` never transforms type symbols, only term symbols,
therefore we can unpickle type parameters without forcing too many
things. tests/neg/leak-type.scala illustrates the new restriction that
this necessitates.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
* Fix varargs in methods (Issue: #1625)
* Fix minor comments
* Change varargs parameter message
* Fix failed test, fix case for constructor
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When typechecking
class A {
C.super.foo()
}
If C isn't an enclosing class, the compiler was throwing because of an
unguarded pattern match.
Fix the issue by checking for ErrorType.
Tested:
Verified that the example above no longer throws.
Added a test.
|
|\
| |
| | |
Fix #2051: allow override T with => T or ()T
|
| | |
|
|\ \
| | |
| | | |
Allow inter-parameter dependencies
|
| |/ |
|
|/
|
|
| |
The bug is already fixed in PR #1724 while fixing another issue
|
|\
| |
| | |
Fix #2066: Don't qualify private members in SelectionProto's...
|
| |
| |
| |
| |
| | |
Now we never match `? { name: T }` with types that
have only a private `name` member. This is what scalac does, too.
|
|/
|
|
|
|
| |
The essential change is that we do not throw away more
precise info of the avoided type if the expected type
is fully defined.
|
|
|
|
|
|
|
|
|
|
| |
The new test `falseView.scala` shows the problem. We might create
an implicit value of some type that happens to be a subtype of Function1.
We might now expect that this gives us an implicit conversion, this
is most often unintended and surprising.
See the comment in Implicits#discardForView for a discussion why
we picked the particular scheme implemented here.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Drop the [type T] syntax, and what's associated to make it work.
Motivation: It's an alternative way of doing things for which there seems
to be little need. The implementation was provisional and bitrotted during
the various iterations to introduce higher-kinded types. So in the end the
complxity-cost for language and compiler was not worth the added benefit
that [type T] parameters provide.
Noe that we still accept _named arguments_ [A = T] in expressions; these are useful
for specifying some parameters and letting others be inferred.
|
|\
| |
| | |
Fix #2030: Don't chain implicit conversions
|
| |
| |
| |
| |
| |
| |
| | |
When inferring a view, we are not allowed to use another
implicit conversion to adapt its result. Fixing this revealed
another problem where we have to re-enable implicit conversions
when pre-typing arguments in overloading resolution.
|
| | |
|
|/ |
|
| |
|
|\
| |
| | |
Fix #2000: Make implicit and non-implicit functions incomparable
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Implicit and non-implicit functions are incomparable with <:<, but are
treated as equivalent with `matches`. This means implicit and non-implicit
functions of the same types override each other, but RefChecks will
give an error because their types are not subtypes.
Also contains a test for #2002.
|
|\ \
| | |
| | | |
Fix off-by-one error in forward reference checking
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
Fix #1747: Improve error message for Scala/Java type mismatch
|
| | | | |
|
| | | | |
|
| |/ /
| | |
| | |
| | | |
Omit the `=>' if a PolyType has a MethodType as result type.
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| | |
Inlining is only well-defined if the body to inline does not
have any errors. We therefore check for errors before we
perform any transformation of trees related to inlining.
The error check is global, i.e. we stop on any error
not just on errors in the code to be inlined. This is a safe
approximation, of course.
|
|\ \
| | |
| | | |
Remove unused flags
|
| |/ |
|
|/
|
|
| |
This is necessary if we ever want to get rid of our dependency on scala-compiler
|
|\
| |
| | |
Fix #1501 - Check trait inheritance condition
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
We need to check a coherence condition between the superclass
of a trait and the superclass of an inheriting class or trait.
|
|\ \
| |/
|/| |
Fix #1907: Improve error message
|
| |
| |
| |
| | |
Updated with SI issues reported by Jason
|
| |
| |
| |
| |
| |
| |
| |
| | |
It seems in most cases this leads to weird behavior and cause
confusing error messages later.
It also means we cannot create an Array[Nothing], except by
passing the classtag explicitly.
|
| |
| |
| |
| |
| | |
If a tree has type error, subtrees may not have an assigned type.
Therefore we should avoid transforming such trees.
|
|\ \
| | |
| | | |
Fix #1644: Disallow inner classes in value classes
|