RefChecks

A class for checking all overriding pairs of class with a given check function

1. 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. If O is non-experimental, M must be non-experimental. 1.13 Under -source future, if O is a val parameter, M must be a val parameter that passes its value on to O. 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 that an extension method is not hidden, i.e., that it is callable as an extension method.

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.

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 the method is an override. (Because the type of the receiver may be narrower in the override.)

If the extension method is nilary, it is always hidden by a member of the same name. (Either the member is nilary, or the reference is taken as the eta-expansion of the member.)

This check is in lieu of a more expensive use-site check that an application failed to use an extension. That check would account for accessibility and opacity. As a limitation, this check considers only public members for which corresponding method parameters are either both opaque types or both not. It is intended to warn if the receiver type from a third-party library has been augmented with a member that nullifies an existing extension.

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 above.

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 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 cls conforms to self types of all parents as seen from cls.thisType
• If self type of cls is explicit, check that it conforms to the self types of all its class symbols.

Check that unary method definition do not receive parameters. They can only receive inferred parameters such as type parameters and implicit parameters.