Attributes
Members list
Type members
Classlikes
Value members
Concrete methods
1.1. M must have the same or stronger access privileges as O. 1.2. O must not be effectively final. 1.3. If M or O are extension methods, they must both be extension methods. (Should be before the check for the need of override
modifier.) 1.4. O is deferred, or M has override
modifier. 1.5. If O is stable, then so is M. 1.6. If O is a type alias, then M is an alias of O. 1.7. If O is an abstract type then 1.7.1 either M is an abstract type, and M's bounds are sharper than O's bounds. or M is a type alias or class which conforms to O's bounds. 1.7.2 higher-order type arguments must respect bounds on higher-order type parameters -- @M (explicit bounds and those implied by variance annotations) -- @see checkKindBounds 1.8. If O and M are values, then 1.8.1 M's type is a subtype of O's type, or 1.8.2 M is of type []S, O is of type ()T and S <: T, or 1.8.3 M is of type ()S, O is of type []T and S <: T, or 1.9. If M is erased, O is erased. If O is erased, M is erased or inline. 1.10. If O is inline (and deferred, otherwise O would be final), M must be inline 1.11. If O is a Scala-2 macro, M must be a Scala-2 macro. 1.12. Under -source future, if O is a val parameter, M must be a val parameter that passes its value on to O. 1.13. If O is non-experimental, M must be non-experimental. 1.14. If O has @publicInBinary, M must have @publicInBinary. 2. Check that only abstract classes have deferred members 3. Check that concrete classes do not have deferred definitions that are not implemented in a subclass. 4. Check that every member with an override
modifier overrides some other member. TODO check that classes are not overridden TODO This still needs to be cleaned up; the current version is a straight port of what was there before, but it looks too complicated and method bodies are far too large.
- Check all members of class
clazz
for overriding conditions. That is for overriding member M and overridden member O:
1.1. M must have the same or stronger access privileges as O. 1.2. O must not be effectively final. 1.3. If M or O are extension methods, they must both be extension methods. (Should be before the check for the need of override
modifier.) 1.4. O is deferred, or M has override
modifier. 1.5. If O is stable, then so is M. 1.6. If O is a type alias, then M is an alias of O. 1.7. If O is an abstract type then 1.7.1 either M is an abstract type, and M's bounds are sharper than O's bounds. or M is a type alias or class which conforms to O's bounds. 1.7.2 higher-order type arguments must respect bounds on higher-order type parameters -- @M (explicit bounds and those implied by variance annotations) -- @see checkKindBounds 1.8. If O and M are values, then 1.8.1 M's type is a subtype of O's type, or 1.8.2 M is of type []S, O is of type ()T and S <: T, or 1.8.3 M is of type ()S, O is of type []T and S <: T, or 1.9. If M is erased, O is erased. If O is erased, M is erased or inline. 1.10. If O is inline (and deferred, otherwise O would be final), M must be inline 1.11. If O is a Scala-2 macro, M must be a Scala-2 macro. 1.12. Under -source future, if O is a val parameter, M must be a val parameter that passes its value on to O. 1.13. If O is non-experimental, M must be non-experimental. 1.14. If O has @publicInBinary, M must have @publicInBinary. 2. Check that only abstract classes have deferred members 3. Check that concrete classes do not have deferred definitions that are not implemented in a subclass. 4. Check that every member with an override
modifier overrides some other member. TODO check that classes are not overridden TODO This still needs to be cleaned up; the current version is a straight port of what was there before, but it looks too complicated and method bodies are far too large.
Value parameters
- makeOverridingPairsChecker
-
A function for creating a OverridePairsChecker instance from the class symbol and the self type
Attributes
Check that an extension method is not hidden, i.e., that it is callable as an extension method.
Check that an extension method is not hidden, i.e., that it is callable as an extension method.
An extension method is hidden if it does not offer a parameter that is not subsumed by the corresponding parameter of the member with the same name (or of all alternatives of an overload).
This check is suppressed if this method is an override.
For example, it is not possible to define a type-safe extension contains
for Set
, since for any parameter type, the existing contains
method will compile and would be used.
If the member has a leading implicit parameter list, then the extension method must also have a leading implicit parameter list. The reason is that if the implicit arguments are inferred, either the member method is used or typechecking fails. If the implicit arguments are supplied explicitly and the member method is not applicable, the extension is checked, and its parameters must be implicit in order to be applicable.
If the member does not have a leading implicit parameter list, then the argument cannot be explicitly supplied with using
, as typechecking would fail. But the extension method may have leading implicit parameters, which are necessarily supplied implicitly in the application. The first non-implicit parameters of the extension method must be distinguishable from the member parameters, as described.
If the extension method is nullary, it is always hidden by a member of the same name. (Either the member is nullary, or the reference is taken as the eta-expansion of the member.)
Attributes
Check that we do not "override" anything with a private method or something that becomes a private method. According to the Scala modeling this is non-sensical since private members don't override. But Java and the JVM disagree, if the private member is a method. A test case is neg/i7926b.scala. Note: The compiler could possibly silently rename the offending private instead of flagging it as an error. But that might mean we see some surprising names at runtime. E.g. in neg/i4564a.scala, a private case class apply
method would have to be renamed to something else.
Check that we do not "override" anything with a private method or something that becomes a private method. According to the Scala modeling this is non-sensical since private members don't override. But Java and the JVM disagree, if the private member is a method. A test case is neg/i7926b.scala. Note: The compiler could possibly silently rename the offending private instead of flagging it as an error. But that might mean we see some surprising names at runtime. E.g. in neg/i4564a.scala, a private case class apply
method would have to be renamed to something else.
Attributes
Check that self type of this class conforms to self types of parents and required classes. Also check that only enum
constructs extend java.lang.Enum
and no user-written class extends ContextFunctionN.
Check that self type of this class conforms to self types of parents and required classes. Also check that only enum
constructs extend java.lang.Enum
and no user-written class extends ContextFunctionN.
Attributes
- Check that self type of
cls
conforms to self types of allparents
as seen fromcls.thisType
- If self type of
cls
is explicit, check that it conforms to the self types of all its class symbols.
Value parameters
- deep
-
If true and a self type of a parent is not given explicitly, recurse to check against the parents of the parent. This is needed when capture checking, since we assume (& check) that the capture set of an inferred self type is the intersection of the capture sets of all its parents
Attributes
Check that unary method definition do not receive parameters. They can only receive inferred parameters such as type parameters and implicit parameters.
Check that unary method definition do not receive parameters. They can only receive inferred parameters such as type parameters and implicit parameters.