| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Re-enable testing the sensibility of comparing instances
of two case classes. In particular, warn if we detect that
the two objects inherit from different case classes. In
addition, avoid emitting misleading warnings when comparing "new C".
|
|\ \ |
|
| | | |
|
| |/ |
|
|/
|
|
| |
More care in warning about bad comparisons.
|
| |
|
|
|
|
|
| |
And eliminating redundancy. Reduced gratuitous usage of typeConstructor
on symbols which don't have type parameters.
|
|
|
|
|
|
|
|
|
|
|
| |
Profiler said checking hasAnnotation thousands of times
is expensive. I always wondered why some things used the
SPECIALIZED flag and others looked for the annotation.
No reason emerges which is apparent from the tests. So:
- mark an annotated symbol specialized at a convenient time
- always look for the flag
- create Symbol#isSpecialized to be consistent with all others
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes test cases mentioned in comment 03/Apr/12 to SI-4540.
Methods are fixed in leaf classes RichDouble|RichFloat|RichLong.
Their superclasses are not modified.
File is-valid-num.scala contains commented tests of
isValidLong|isValidFloat|isValidLong,
but they are not added anywhere now.
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
eqTypeCode(Number) is equivalent to typeCode(Number).
CHAR code is impossible because java.lang.Character is not subclass of java.lang.Number.
|
| |/ |
|
|/
|
|
|
| |
Another "three yards and a cloud of dust" in my ongoing
battle against flag uncertainty.
|
|
|
|
|
|
|
|
| |
One leads to the other.
Easing some more specific typing into Symbols.
Getting a handle on when where and how people rename
symbols to suit their fancies.
|
|\ |
|
| |
| |
| |
| | |
Also trimmed some cruft which had accrued in recent work.
|
|\ \ |
|
| |\ \ |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
We don't use Option[Symbol].
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The example from the ticket is committed as a neg test.
The problem is that a super.m on an abstract override
member m has no concrete implementation, that is, the
trait T is not mixed in after a class C with a concrete m.
The error is noticed at phase mixin when the super accessor
is added to the concrete mixer. (Pun alert?) When super.m
is rebound, no concrete matching symbol is found up the
linearization.
Previously, it was asserted that such a symbol should
be found, but since this is our first opportunity to
detect that there is none, an error should be emitted
instead. The new message is of the form:
Member method f of mixin trait T2 is missing a concrete super implementation.
Additionally, a couple of flag tests were changed to use isAbstractOverride.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It makes me a bit nervous that NumericRange[Int] will
get different wrong values in overflow situations compared
to Range due to the missing toLong though.
It could probably need some investigation if reordering the
operations can rule out wrong values, e. g. only fail when
the fold also fails.
Apart from that, it might make sense to just throw an exception
if an overflow happens instead of silent overflow.
|
| |_|/
|/| |
| | |
| | | |
And test case for SI-5591.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Don't let OverloadedTypes reach the backend. When you want a
method from a particular symbol, avoid getMember, which may inflict
upon you an OverloadedType if an inherited member has the same
name. Instead, use the (just now appearing) definitions.getDecl.
|
| | |
| | |
| | |
| | | |
That's why we have those nice test cases.
|
| | | |
|
| | |
| | |
| | |
| | | |
Reusing small, simple methods rather than lots of cut and paste.
|
|\ \ \ |
|
| | | | |
|
|\ \ \ \ |
|
| | \ \ \ | |
| | \ \ \ | |
| | \ \ \ | |
| | \ \ \ | |
| | \ \ \ | |
| | \ \ \ | |
| |\ \ \ \ \ \ \
| | |_|_|_|_|_|/
| |/| | | | | |
| | | | | | | | |
'refs/pull/356/head'; commit 'refs/pull/337/head'; commit 'refs/pull/339/head' into develop
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Changed StringContext.f which implements the formatted string interpolator.
Any '%' not in formatting position is left in the resulting string literally.
However, instead of adding '%s' format holders and extending the args with
"%" expressions, these '%' are replaced by '%%'. The formatter then converts
'%%' (percent formatter) to the literal % (\u0025).
The interpolation tests still pass.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Changed StringContext.f which implements the formatted
string interpolator.
Any '%' not in formatting position is left in the resulting string literally.
However, instead of adding %s format holders and extending the args with "%"
expressions, these '%' are replaced by '%%'. The formatter then converts '%%'
(percent formatter) to the literal '%' (\u0025). This also simplifies the spec.
The interpolation tests still pass.
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This change fixes a bug in class StringContext.scala.
Parts were not correctly added to the resulting string.
This commit includes a test case which covers the
example reported in the bug.
Closes SI-5614.
|
| | | | |/ / / |
|
| | |/ / / / |
|
|/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Finally my dream of orderliness is within sight.
It's all pretty self-explanatory. More polymorphism, more immutable
identity, more invariants.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I just can't shake the feeling more people should see the
things that I see.
scalac -Dscalac.debug.syms foo.scala
|
| | | | |
| | | | |
| | | | |
| | | | | |
Don't type pattern trees with annotations still attached.
|
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Avoid explicit type arguments which don't conform to bounds
where they could be successfully inferred.
I had to disable one "neg" test which is no longer neg.
Can anyone clue me in as to whether it is important?
|
| | | | |
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The source of many bugs over the years is that the first is
represented as a TypeRef and the second a SingleType. Over a
great period of time I figured out how to shield us from the
more obvious bug manifestations, but a recent comment by adriaan
jarred me into realizing that we can fix it at the source.
This commit changes <:< and =:= to recognize when those two
representations are being compared and to treat them as equivalent
regardless of which is on the left. The reason I don't quash one
representation entirely is that a fair bit of code depends on
singleton types having an underlying type which is not the same,
and regardless of that it would entail more changes and more risk.
The change allows removing the type inference conditions which
worried about this, and also fixes SI-4910.
scala> val t1 = typeRef(ScalaPackageClass.thisType, NoneModule.moduleClass, Nil)
t1: $r.intp.global.Type = None.type
scala> val t2 = t1.narrow
t2: $r.intp.global.Type = None.type
scala> (t1.getClass, t2.getClass)
res20: (Class[?0], Class[?0]) forSome { type ?0 <: $r.intp.global.Type; type ?0 <: $r.intp.global.Type } =
(class scala.reflect.internal.Types$ModuleTypeRef,class scala.reflect.internal.Types$UniqueSingleType)
scala> ((t1 =:= t2, t2 =:= t1, t1 <:< t2, t2 <:< t1))
res21: (Boolean, Boolean, Boolean, Boolean) = (true,true,true,true)
|
| | | | |
| \ \ | |
|\ \ \ \ |
|
| | | |/
| | |/| |
|
|/ / / |
|
| | | |
|
|\ \ \ |
|
| | \ \ | |
| | \ \ | |
| | \ \ | |
| | \ \ | |
| | \ \ | |
| | \ \ | |
| |\ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | | |
'dlwh/issues/5632', 'jsuereth/feature/import-jars-from-maven', 'nadezhin/master' and 'axel22/feature/collection-concurrent' into develop
|
| | | | | |\| |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Conflicts:
src/library/scala/collection/JavaConversions.scala
src/library/scala/collection/JavaConverters.scala
Add one test for concurrent map conversion.
|