| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
of the functionality that one can straightforwardly obtain from the
capabilities of java.io.File in java 5, but written with an eye on the
significantly more capable (if not significantly more appealing) nio2
API in openjdk.
|
| |
|
|
|
|
|
|
| |
A bunch of cleanups around Ordered & Ordering, and provided
PartialOrdering with the "partial" part it had never been given.
|
|
|
|
|
|
|
| |
added manifests to most parts of standard library which deal with
arrays. One test is temporarily disabled, as it shows a deep problem
with multi-dimensional arrays (which was present all along).
|
|
|
|
|
| |
Fix and test case for #2187 and its duplicate #2192.
|
| |
|
| |
|
|
|
|
|
| |
Fixed faulty constant propagation in the optimizer (#2279)
|
|
|
|
|
|
| |
Some functionalization achieved while trying to figure out if we can
make reduceLeft work right on Stream.
|
| |
|
| |
|
|
|
|
|
|
| |
Refined manifest checking in preparation for arrays with manifests
change.
|
|
|
|
|
| |
fixing bootstrapping problem wrt removing identity as an implicit
|
|
|
|
|
| |
Taking a little more advantage of some recent abstractions.
|
| |
|
|
|
|
|
| |
Some minor logic simplifying falling out of equality work.
|
| |
|
|
|
|
|
| |
A few straggler deprecations with straightforward enough resolutions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These might be the last of the deprecation warnings I can obey in good
conscience without doing some less robotic work first. Most of the
remaining deprecations do any of:
* deprecate in favor of non-existent function
* deprecate in favor of function which doesn't quite work yet
e.g. List.{ map2, forall2 }
* deprecate in favor of function which blows the stack
(Iterator.append says to use ++ but this ends poorly, see nsc's TreeSet)
* deprecate in favor of a function which doesn't do the same thing
e.g. List.-- says to use diff instead, but
List(1,1) -- List(1) != List(1,1) diff List(1)
|
| |
|
| |
|
|
|
|
|
| |
Reverted r18344 as it is interacting badly with package objects.
|
|
|
|
|
|
|
| |
in the end had to disable conforms as view in tryImplicit (see comment
in removeNames in NamesDefaults) fixed check file for viewtest added
newTermName for conforms to StdNames, so removed the previous weirdness
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
replaced the implicit `identity` coercion by `conforms`, which can be
used to encode generalised constraints the introduction of `conforms`
revealed a bug in adaptToMember, which was inferring views while already
inferring one, which gave rise to diverging implicits. Predef.identity
is no longer special as far as the compiler is concerned.
because conforms/identity was no longer prevented from being used as
a view (which does not make sense, but preventing it shouldn't be
necessary), removeNames in NamesDefaults suddenly didn't detect all
ambiguities because it relied on tryTypedApply failing fixed by using an
EmptyTree as an ambiguous argument instead of the argument, so failure
is guaranteed
fixed check file for t0590
new starr
fixed the weirdest bug ever: don't know why, but can't change the total
number of calls to newTermName in StdNames (so take away the one for
"identity", give one back, doesn't matter where --> see "utterweirdness"
at the end) the problem manifested itself by not finding Nil. This only
happens during start up (when the scala/package.scala file hasn't been
compiled yet), when Nil is required before List (because that would have
forced Nil to be loaded).
|
| |
|
|
|
|
|
|
| |
added partial manifests (now called manifests), as opposed to
FullManifests
|
|
|
|
|
|
|
|
| |
This reverts commits
ce0ebb316c094814d72cc7dfcc7ac8e7c22f16c2
cd61aed60d71441308967bece13d87384a59d3e8
0becf263fe8f1dc74bc7277be5d2c6ed04047923
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
because conforms/identity was no longer prevented from being used as
a view (which does not make sense, but preventing it shouldn't be
necessary), removeNames in NamesDefaults suddenly didn't detect all
ambiguities because it relied on tryTypedApply failing fixed by using an
EmptyTree as an ambiguous argument instead of the argument, so failure
is guaranteed
fixed check file for t0590
also reintroduced conforms, because we now have a new starr
|
|
|
|
|
| |
Gave spawn and future a default implicit to address ticket #2274.
|
|
|
|
|
|
|
|
|
| |
replaced the implicit `identity` coercion by `conforms`, which can be
used to encode generalised constraints the introduction of `conforms`
revealed a bug in adaptToMember, which was inferring views while already
inferring one, which gave rise to diverging implicits. Predef.identity
is no longer special as far as the compiler is concerned.
|
| |
|
| |
|
|
|
|
|
|
|
| |
A bunch of cleanup on scriptrunner and fsc performed in a quest to fix
#1889. I understand why #1889 happens now but I believe fixing it is
going to require adjusting the logic in SymbolLoaders.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Improvements in positions assigned to expresssions using assignment
operators.
|
|
|
|
|
| |
2. Relaxed bounds checking rules for existential types.
|
|
|
|
|
|
| |
Fixed #1560 (which was a typing hole, so some library classes had to be
fixed)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
improving fix of #2246: optimised isDifferentTypeConstructor
removed typeConstructor(Boolean), using hasDifferentTypeSymbol instead
switched to new subtyping algorithm (isSubType2)
substitution now uses appliedType
appliedType ensures Any/Nothing never have type args (so don't need to shortcut isSubArgs in firstTry when sym == AnyClass)
appliedType ignores TypeVar's for now (must deal with them, since they
arise during substitution) when tcpoly infer is integrated, TypeVar's
also have type arguments and this case in appliedType must be updated
maybe appliedType should become a member of Type (and rename to
applyTypeArgs?)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
be more careful in isSubType for abstract types: type *constructors*
must be different, not the whole type, which includes type arguments
typeConstructor needed to instantiate the resulting type constructor
with fresh type arguments (derived from type params), otherwise we end
up in the higher-kinded case, and isDifferentTypeConstructor might try
to compare polytypes with type params
that have different (higher-order) arities --> this may still arise on other cases, though -- should fix this while working on #2210
|
|
|
|
|
|
| |
fix for 513: use deep ForeachTypeTraverser in doTypeTraversal instead of
shallow one test case+checkfile for #513
|
| |
|
| |
|
| |
|