Change static typing so that inherited noSuchMethod silences errors,

docs/language/dartLangSpec.tex

 \documentclass{article}
 \usepackage{epsfig}
 \usepackage{color}
 \usepackage{dart}
 \usepackage{bnf}
 \usepackage{hyperref}
 \usepackage{lmodern}
 \newcommand{\code}[1]{{\sf #1}}
 \title{Dart Programming Language  Specification \\
 {\large Version 1.9}}
@@ skipping 1088 matching lines @@
 % so does an abstract method override a method in a superclass or not? Does the superclass method get inherited or not?  This generally makes the spec inconsistent, as there is no simple answer.
 % For example - if we say it does not override, then the superclass member is inherited, in which case the rules for warning break down, and also there is question of whether there are two definitions of the same name.
 % But if we do override, method lookup rules break down.  So several things need revisiting.
 
 \rationale{
 The purpose of an abstract method is to provide a declaration for purposes such as type checking and reflection. In classes used as mixins, it is often useful to introduce such declarations for methods that the mixin expects will be provided by the superclass the mixin is applied to.
 }
 %always results in a run-time error. This must be \code{NoSuchMethodError} or an instance of a subclass of \code{NoSuchMethodError}, such as \code{AbstractMethodError}.
 
 \LMHash{}
-It is a static warning if an abstract member is declared or inherited in a concrete class unless that member overrides a concrete one.
+It is a static warning if an abstract member $m$ is declared or inherited in a concrete class $C$ unless:
+\begin{itemize}
+\item  $m$ overrides a concrete member, or 
+\item $C$ has a \cd{noSuchMethod()} method distinct from the one declared in class \cd{Object}.
+\end{itemize}
 
 \rationale {
 We wish to warn if one declares a concrete class with abstract members. However,  code like the following should work without warnings:
 }
 
 \begin{dartCode}
  class Base \{
     int get one =$>$ 1;
  \}
 
@@ skipping 686 matching lines @@
 \item It is a static warning if a concrete class has an abstract member (declared or inherited).
 \item It is a static warning and a dynamic error to call a non-factory constructor of an abstract class  (\ref{new}). 
 \item If a class defines an instance member named $m$, and any of its superinterfaces have a  member named $m$, the interface of the class overrides $m$.
 \item  An interface inherits all  members of its superinterfaces that are not overridden and not members of multiple superinterfaces.
 \item  If multiple superinterfaces of an interface define a member with the same name $m$, then at most one member is inherited. That member (if it exists) is the one whose type is a subtype of all the others. If there is no such member, then:
 \begin{itemize}
   \item  A static warning is given.
   \item  If possible the interface gets a member named $m$ that has the minimum number of required parameters among all the members in the superinterfaces, the maximal number of    positionals, and the superset of named parameters.  The types of these are all \DYNAMIC{}. If this is impossible then no member $m$ appears in the interface.
   \end{itemize}  (\ref{interfaceInheritanceAndOverriding})
 \item  Rule \ref{typeSigAssignable} applies to interfaces as well as classes  (\ref{interfaceInheritanceAndOverriding}).
-\item  It is a static warning if a concrete class does not have an implementation for a  method in any of its superinterfaces  unless it declares  its own \cd{noSuchMethod} method (\ref{superinterfaces}). 
+\item  It is a static warning if a concrete class does not have an implementation for a  method in any of its superinterfaces  unless it has a \cd{noSuchMethod} method (\ref{superinterfaces}). 
 \item The identifier of a named constructor cannot be the same as the name of a member declared (as opposed to inherited) in the same class (\ref{constructors}).
 \end{enumerate}
 }
 
 
 %Can we have abstract getters and setters?
 
 \subsection{ Superinterfaces}
 \LMLabel{superinterfaces}
 % what about rules about classes that fail to implement their interfaces?
@@ skipping 13 matching lines @@
 It is a compile-time error if the superclass of a class $C$ is specified as a superinterface of $C$.
 
 \rationale{
 One might argue that it is harmless to repeat a type in the superinterface list, so why make it an error? The issue is not so much that the situation described in program source is erroneous, but that it is pointless. As such, it is an indication that the programmer may very well have meant to say something else - and that is a mistake that should be called to her or his attention.  Nevertheless, we could simply issue a warning; and perhaps we should and will. That said, problems like these are local and easily corrected on the spot, so we feel justified in taking a harder line. 
 }
 
 \LMHash{}
 It is a compile-time error if the interface of a class $C$ is a superinterface of itself.
 
 \LMHash{}
-Let $C$ be a concrete class that does not declare its own \code{noSuchMethod()} method.
+Let $C$ be a concrete class that does not have a \code{noSuchMethod()} method distinct from the one declared in class \cd{Object}.
 It is a static warning if the implicit interface of  $C$ includes an instance member $m$ of type $F$ and $C$ does not declare or inherit a corresponding non-abstract instance member $m$ of type $F'$ such that $F' <: F$. 
 
 \commentary{A class does not inherit members from its superinterfaces. However, its implicit interface does.
 }
 
 
 \rationale {
 We choose to issue these warnings only for concrete classes; an abstract class might legitimately be designed with the expectation that concrete subclasses will implement part of  the interface.
-We also disable these warnings if a \code{noSuchMethod()} declaration is present. In such cases, the supported interface is going to be implemented via \code{noSuchMethod()} and no actual declarations of the implemented interface's members are needed. This allows proxy classes for specific types to be implemented without provoking type warnings.
-
-In addition, it may be useful to suppress these warnings if \code{noSuchMethod} is inherited, However, this may suppress meaningful warnings and so we choose not to do so. If one does want to suppress the warnings in a subclass, one can define a simple implementation of \code{noSuchMethod} in the subclass:
+We also disable these warnings if a \code{noSuchMethod()} declaration is present or inherited from any class other than \cd{Object}. In such cases, the supported interface is going to be implemented via \code{noSuchMethod()} and no actual declarations of the implemented interface's members are needed. This allows proxy classes for specific types to be implemented without provoking type warnings.
 }
 
-\begin{dartCode}
-noSuchMethod(inv) =$>$ \SUPER.noSuchMethod(inv);
-\end{dartCode}
 
 \LMHash{}
 It is a static warning if the implicit interface of  a class $C$ includes an instance member $m$ of type $F$ and $C$ declares or inherits a corresponding instance member $m$ of type $F'$ if  $F'$ is not a subtype of $F$. 
 
 \rationale{
 However, if a class does explicitly declare a member that conflicts with its superinterface, this always yields a static warning.
 
 }
 %It is a static warning if an imported superinterface of a class $C$ declares private members.
 
@@ skipping 4943 matching lines @@
 \rationale{
 The naive reader might conclude that, since it is not legal to declare a function with an empty optional parameter list, these rules are pointless. However, they induce  useful relationships between function types that declare no optional parameters and those that do.
 }
 
 \LMHash{}
 A function type $T$ may be assigned to a function type $S$, written  $T \Longleftrightarrow S$, iff  $T <: S$. 
 
 \LMHash{}
 % ensure that Object  and dynamic may be assign dot a function type
 A function is always an instance of some class that implements the class \code{Function} and implements a \CALL{} method with the same signature as the function. All function types are subtypes of \code{Function}.
-If a type $I$ includes an instance method named \CALL{}, and the type of \CALL{} is the function type $F$, then $I$ is considered to be more specific than $F$.  It is a static warning if a concrete class implements \cd{Function} and does not have a concrete method named \CALL{} unless that class declares its own implementation of \cd{noSuchMethod()}.
+If a type $I$ includes an instance method named \CALL{}, and the type of \CALL{} is the function type $F$, then $I$ is considered to be more specific than $F$.  It is a static warning if a concrete class implements \cd{Function} and does not have a concrete method named \CALL{} unless that class has an implementation of \cd{noSuchMethod()} distinct from the one declared in class \cd{Object}.
 
 
 
 
 %\commentary{Need to specify how a function values dynamic type is derived from its static signature.}
 
 \LMHash{}
 A function type $(T_1, \ldots T_{k}, [T_{k+1}  \ldots, T_{n+m}]) \rightarrow T$ is a more specific than the
 function type $(S_1, \ldots, S_{k+j}, [S_{k+j+1} \ldots, S_{n}]) \rightarrow S$, if all of the following conditions are met:
 \begin{enumerate}
@@ skipping 497 matching lines @@
 
 The invariant that each normative paragraph is associated with a line
 containing the text \LMHash{} should be maintained.  Extra occurrences
 of \LMHash{} can be added if needed, e.g., in order to make
 individual \item{}s in itemized lists addressable.  Each \LM.. command
 must occur on a separate line.  \LMHash{} must occur immediately
 before the associated paragraph, and \LMLabel must occur immediately
 after the associated \section{}, \subsection{} etc.
 
 ----------------------------------------------------------------------