Adjusted superclasses to make a mixin application superclass abstract

We should avoid the situation where `class C extends A with M {}`
requires generation of noSuchMethod forwarders _in the superclass
`A with M`_ when neither `A` nor `M` has an implementation of
`foo`, but `A with M` has a non-trivial noSuchMethod.

If we _do_ generate those nSM forwarders, that will just obscure that
any attempt to invoke `super.foo()` in `C` should be an error.

Note that this is about generating forwarders _in the mixin application
which is the superclass_, it is not about copy-down of forwards from
the class `M` that was used to obtain the mixin in the first place.

Also note that it would be inconvenient to require all methods to be
implemented in `A with M` as used in `abstract C extends A with M {}`,
and it would also be rather funny if we were to say that `A with M` is
abstract when `C` is abstract, and concrete when `C` is concrete.

So I think the only reasonable choice is to make those superclasses
which are mixin applications abstract.

Note that dart:mirrors ought to reflect this, in a separate issue,
if it is not already the case.

Change-Id: If221b2c73b17bd55017d4d5ee4fdb8daf203e195
Reviewed-on: https://dart-review.googlesource.com/76640
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>

docs/language/dartLangSpec.tex

@@ -2571,17 +2571,35 @@ \subsection{Static Methods}
 \subsection{Superclasses}
 \LMLabel{superclasses}
 
-\LMHash{}
-The superclass $S^\prime$ of a class $C$ that has a with clause \code{\WITH{} $M_1, \ldots,\ M_k$} and an extends clause \code{\EXTENDS{} $S$} is the application of mixin composition (\ref{mixins}) $M_k* \cdots * M_1$ to $S$. The name $S^\prime$ is a fresh identifier.
-If no \WITH{} clause is specified then the \EXTENDS{} clause of a class $C$ specifies its superclass.
+%% TODO(eernst): We need to say that the superclass which is obtained
+%% by mixin application is generic when $C$ is generic, or at least
+%% when one or more of $C$'s type variables are used by the classes
+%% in the \EXTENDS{} or \WITH{} clause of $C$. It says below that
+%% these clauses are in the type parameter scope of $C$, but that does
+%% not allow us to talk about the superclass as an actual, stand-alone
+%% class (unless we start defining nested classes, such that the
+%% superclass can be declared in that scope).
+
+\LMHash{}
+The superclass $S'$ of a class $C$ whose declaration has a with clause
+\code{\WITH{} $M_1, \ldots,\ M_k$}
+and an extends clause
+\code{\EXTENDS{} $S$}
+is the abstract class obtained by application of
+mixin composition (\ref{mixins}) $M_k* \cdots * M_1$ to $S$.
+The name $S'$ is a fresh identifier.
+If no \WITH{} clause is specified then the \EXTENDS{} clause of
+a class $C$ specifies its superclass.
 If no \EXTENDS{} clause is specified, then either:
 \begin{itemize}
 \item $C$ is \code{Object}, which has no superclass. OR
-\item Class $C$ is deemed to have an \EXTENDS{} clause of the form \code{\EXTENDS{} Object}, and the rules above apply.
+\item Class $C$ is deemed to have an \EXTENDS{} clause of the form
+\code{\EXTENDS{} Object}, and the rules above apply.
 \end{itemize}
 
 \LMHash{}
-It is a compile-time error to specify an \EXTENDS{} clause for class \code{Object}.
+It is a compile-time error to specify an \EXTENDS{} clause
+for class \code{Object}.
 
 \begin{grammar}
 <superclass> ::= \EXTENDS{} <type>