| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Commit f32a32b1b33c9d7ccd62467e3e10cb69930023c8 introduced the ability
to override objects with other objects. The exception that allows
these overrides (where the usual subtyping check fails) was applied to
all members whose type is a module class. This is too broad, however,
because it not only applies to members of the form `object foo` but
also `def foo: bar.type` (where `bar` is an `object`).
The fix is to restrict the exception to those cases where both
definitions actually are objects.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Investigating the useful output of devWarning (-Xdev people,
it's good for you) led back to this comment:
"normalize to get rid of type aliases"
You may know that this is not all the normalizing does.
Normalizing also turns TypeRefs with unapplied arguments
(type constructors) into PolyTypes. That means that when
typedParentType would call typedTypeConstructor it would
find its parent had morphed into a PolyType. Not that it
noticed; it would blithely continue and unwittingly discard
the type arguments by way of appliedType (which smoothly
logged the incident, thank you appliedType.)
The simplification of typedTypeConstructor:
There was a whole complicated special treatment of AnyRef
here which appears to have become unnecessary. Removed special
treatment and lit a candle for regularity.
Updated lots of tests regarding newly not-so-special AnyRef.
|
| |
|
|
|
| |
Yet more funnelling of immutable creation-time known information
into the identities of symbols and types.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Important note for busy commit log skimmers ***
Symbol method "fullName" has been trying to serve the dual role of "how
to print a symbol" and "how to find a class file." It cannot serve both
these roles simultaneously, primarily because of package objects but
other little things as well. Since in the majority of situations we want
the one which corresponds to the idealized scala world, not the grubby
bytecode, I went with that for fullName. When you require the path to a
class (e.g. you are calling Class.forName) you should use javaClassName.
package foo { package object bar { class Bippy } }
If sym is Bippy's symbol, then
sym.fullName == foo.bar.Bippy
sym.javaClassName == foo.bar.package.Bippy
*** End important note ***
There are many situations where we (until now) forewent revealing
everything we knew about a type mismatch. For instance, this isn't very
helpful of scalac (at least in those more common cases where you didn't
define type X on the previous repl line.)
scala> type X = Int
defined type alias X
scala> def f(x: X): Byte = x
<console>:8: error: type mismatch;
found : X
required: Byte
def f(x: X): Byte = x
^
Now it says:
found : X
(which expands to) Int
required: Byte
def f(x: X): Byte = x
^
In addition I rearchitected a number of methods involving:
- finding a symbol's owner
- calculating a symbol's name
- determining whether to print a prefix
No review.
|
|
|
Various and sundry manipulations to allow for objects to be overridden
when the mood is right. It is not enabled by default.
The major contributor of change turned out to be the decoupling of
the FINAL flag (and the "isFinal" test which examines only that flag)
and the many semantics which were attributed to this interpretation
of finality in different circumstances. Since objects no longer have
the FINAL flag automatically applied (only top-level objects and those
marked final in source code do) we need apply a more nuanced test.
Fortunately there is such a nuanced test: isEffectivelyFinal,
which is always true if the FINAL flag is set but also in various
other circumstances. In almost every case, you should be testing
"isEffectivelyFinal", not "isFinal".
To enable overridable objects, use:
-Yoverride-objects
-Xexperimental // includes the above and others
Remain to be done: working out transition logistics. Most likely this
would involve bumping the scala signature version, and all objects in
versions before that would be assumed final.
Review by moors.
|
