Updates for 1.10: warnings when for-in uses an expresison that has no iterator; assorted typos.

docs/language/dartLangSpec.tex

Index: docs/language/dartLangSpec.tex
diff --git a/docs/language/dartLangSpec.tex b/docs/language/dartLangSpec.tex
index 9c1f5686c489646191df2be507a0b6f54d14a016..0e9aa5bdd7cc126ddf9b913d514fb914a669508c 100644
--- a/docs/language/dartLangSpec.tex
+++ b/docs/language/dartLangSpec.tex
@@ -7,7 +7,7 @@
 \usepackage{lmodern}
 \newcommand{\code}[1]{{\sf #1}}
 \title{Dart Programming Language  Specification \\
-{\large Version 1.9}}
+{\large Version 1.10}}
 
 % For information about Location Markers (and in particular the
 % commands \LMHash and \LMLabel), see the long comment at the
@@ -2344,7 +2344,7 @@ An {\em expression} is a fragment of Dart code that can be evaluated at run time
 
 \begin{grammar}
 {\bf primary:}thisExpression;
-      \SUPER{} assignableSelector;
+      \SUPER{} unconditionalAssignableSelector;
       functionExpression;
       literal;
       identifier;
@@ -2748,6 +2748,10 @@ Multiline strings are delimited by either matching triples of single quotes or m
  \rationale{
  The idea is to ignore whitespace, where whitespace is defined as tabs, spaces and newlines. These can be represented directly, but since for most characters prefixing by backslash is an identity, we allow those forms as well.
  }
+ 
+ % could be clearer. Is the first line in  """\t
+ %    """ ignored not. It depends if we mean whitespace before escapes are interpreted,
+ % or after, or both.  See https://code.google.com/p/dart/issues/detail?id=23020
 
 \LMHash{}
 Strings support escape sequences for special characters. The escapes are:
@@ -3916,7 +3920,7 @@ $\SUPER{}.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$.
 Evaluation of $i$ proceeds as follows:
 
 \LMHash{}
-First, the argument list $(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ is evaluated  yielding actual argument objects $o_1, \ldots , o_{n+k}$. Let $S$ be the superclass of the immediately enclosing class, and let $f$ be the result of looking up method (\ref{ordinaryInvocation})  $m$ in $S$  with respect to the current library $L$. 
+First, the argument list $(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ is evaluated  yielding actual argument objects $o_1, \ldots , o_{n+k}$. Let $S$ be the superclass of the immediately enclosing class, and let $f$ be the result of looking up method (\ref{methodLookup})  $m$ in $S$  with respect to the current library $L$. 
 Let $p_1 \ldots p_h$ be the required parameters of $f$,  let $p_1 \ldots p_m$ be the positional parameters of $f$ and let $p_{h+1}, \ldots, p_{h+l}$ be the optional parameters declared by $f$.
 
 \LMHash{}
@@ -3990,7 +3994,7 @@ Property extraction can be either {\em conditional} or {\em unconditional}.
 Tear-offs using the \cd{ x\#id}  syntax cannot be conditional at this time; this is inconsistent, and is likely to be addressed in the near future, perhaps via  notation such as  \cd{ x?\#id} . As indicated in section \ref{ecmaConformance}, experimentation in this area is allowed.
 }
 
-Evaluation of a {\em conditional property extraction expression} $e$ of the form $e_1?.id$  is equivalent to the evaluation of the expression  $((x) => x == \NULL ? \NULL : x.id)(e_1)$. The static type of $e$ is the same as the static type of $e_1.id$. Let $T$ be the static type of $e_1$ and let $y$ be a fresh variable o type $T$. Exactly the same static warnings that would be caused by $y.id$ are also generated in the case of $e_1?.id$.
+Evaluation of a {\em conditional property extraction expression} $e$ of the form $e_1?.id$  is equivalent to the evaluation of the expression  $((x) => x == \NULL ? \NULL : x.id)(e_1)$. The static type of $e$ is the same as the static type of $e_1.id$. Let $T$ be the static type of $e_1$ and let $y$ be a fresh variable of type $T$. Exactly the same static warnings that would be caused by $y.id$ are also generated in the case of $e_1?.id$.
 
 \commentary{
 One might be tempted to conclude that for $e \ne \NULL{}$, $e?.v$ is always equivalent to $e.v$. However this is not the case. If $e$ is a type literal representing a type with static member $v$, then $e.v$ refers to that member, but $e?.v$ does not.
@@ -4155,7 +4159,7 @@ This restriction is in line with other limitations on the use of prefixes as obj
 \LMHash{}
 Let $T$ be the static type of $e$. It is a static type warning if $T$ does not have an accessible instance method or getter named $m$ unless either:
 \begin{itemize}
-\item $T$ or a superinterface of $T$ is annotated with an annotation denoting a constant identical to the constant proxy defined in \cd{dart:core}. Or
+\item $T$ or a superinterface of $T$ is annotated with an annotation denoting a constant identical to the constant \code{@proxy} defined in \cd{dart:core}. Or
 \item $T$ is \cd{Type}, $e$ is a constant type literal and the class corresponding to $e$ declares an accessible static method or getter named $m$.
 \end{itemize}
 
@@ -4398,7 +4402,7 @@ Evaluation of an assignment $a$ of the form $v$ \code{=} $e$ proceeds as follows
 % \item Otherwise, the assignment is equivalent to the assignment \code{ \THIS{}.$v$ = $e$}. 
 % \end{itemize}
  
-%Otherwise,  
+%Otherwise 
 
 \LMHash{}
 Let $d$ be the innermost declaration whose name is $v$ or $v=$, if it exists.
@@ -4407,6 +4411,8 @@ Let $d$ be the innermost declaration whose name is $v$ or $v=$, if it exists.
 If $d$ is the declaration of a local variable, the expression $e$ is evaluated to an object $o$. Then, the variable $v$ is bound to $o$ unless $v$ is \FINAL{} or \CONST{}, in which case a dynamic error occurs.
 If no error occurs, the value of the assignment expression is $o$.  
 
+% add local functions per bug 23218
+
 \LMHash{}
 If $d$ is the declaration of a library variable, top level getter or top level setter, the expression $e$ is evaluated to an object $o$. Then the setter $v=$ is invoked with its formal parameter bound to $o$. The value of the assignment expression is $o$.  
 
@@ -4535,7 +4541,13 @@ It is a compile-time error to invoke any of the setters of class \cd{Object} on
 \LMLabel{compoundAssignment}
 
 \LMHash{}
-Evaluation of a compound assignment of the form $v$ {\em ??=} $e$ is equivalent to the evaluation of the expression  $((x) => x == \NULL{}$ ?  $v=e : x)(v)$ where $x$ is a fresh variable that is not used in $e$. Evaluation of a compound assignment of the form $C.v$ {\em ??=} $e$, where $C$ is a type literal, is equivalent to the evaluation of the expression  $((x) => x == \NULL{}$?  $C.v=e: x)(C.v)$ where $x$ is a fresh variable that is not used in $e$. Evaluation of a compound assignment of the form $e_1.v$ {\em ??=} $e_2$ is equivalent to the evaluation of the expression  $((x) =>((y) => y == \NULL{}$ ? $ x.v = e_2: y)(x.v))(e_1)$ where $x$ and $y$ are distinct fresh variables that are not used in $e_2$. Evaluation of a compound assignment of the form  $e_1[e_2]$  {\em ??=} $e_3$ is equivalent to the evaluation of the expression  
+Evaluation of a compound assignment of the form $v$ {\em ??=} $e$ is equivalent to the evaluation of the expression  $((x) => x == \NULL{}$ ?  $v=e : x)(v)$ where $x$ is a fresh variable that is not used in $e$. Evaluation of a compound assignment of the form $C.v$ {\em ??=} $e$, where $C$ is a type literal, is equivalent to the evaluation of the expression  $((x) => x == \NULL{}$?  $C.v=e: x)(C.v)$ where $x$ is a fresh variable that is not used in $e$. 
+
+\commentary {
+The two rules above also apply when the variable v or the type C is prefixed.
+}
+
+Evaluation of a compound assignment of the form $e_1.v$ {\em ??=} $e_2$ is equivalent to the evaluation of the expression  $((x) =>((y) => y == \NULL{}$ ? $ x.v = e_2: y)(x.v))(e_1)$ where $x$ and $y$ are distinct fresh variables that are not used in $e_2$. Evaluation of a compound assignment of the form  $e_1[e_2]$  {\em ??=} $e_3$ is equivalent to the evaluation of the expression  
 $((a, i) => ((x) => x == \NULL{}$ ?  $a[i] = e_3: x)(a[i]))(e_1, e_2)$ where $x$, $a$ and $i$ are distinct fresh variables that are not used in $e_3$. Evaluation of a compound assignment of the form $\SUPER.v$  {\em ??=} $e$ is equivalent to the evaluation of the expression  $((x) => x == \NULL{}$ ? $\SUPER.v = e: x)(\SUPER.v)$ where $x$ is a fresh variable that is not used in $e$.
 
 \LMHash{}
@@ -4550,7 +4562,7 @@ The static type of a compound assignment of the form $v$ {\em ??=} $e$ is the le
 The static type of a compound assignment of the form  $C.v$ {\em ??=} $e$  is the least upper bound of the static type of $C.v$ and the static type of $e$.  Exactly the same static warnings that would be caused by $C.v = e$ are also generated in the case of $C.v$ {\em ??=} $e$.
 
 \LMHash{}
-The static type of a compound assignment of the form $e_1.v$  {\em ??=} $e_2$ is the least upper bound of the static type of $e_1.v$ and the static type of $e_2$. Let $T$ be the static type of $e_1$ and let $z$ be a fresh variable of type $T$. Exactly the same static warnings that would be caused by $z.v = e$ are also generated in the case of $e_1.v$  {\em ??=} $e_2$.
+The static type of a compound assignment of the form $e_1.v$  {\em ??=} $e_2$ is the least upper bound of the static type of $e_1.v$ and the static type of $e_2$. Let $T$ be the static type of $e_1$ and let $z$ be a fresh variable of type $T$. Exactly the same static warnings that would be caused by $z.v = e_2$ are also generated in the case of $e_1.v$  {\em ??=} $e_2$.
 
 \LMHash{}
 The static type of a compound assignment of the form $e_1[e_2]$  {\em ??=} $e_3$  is the least upper bound of the static type of $e_1[e_2]$ and the static type of $e_3$. Exactly the same static warnings that would be caused by $e_1[e_2] = e_3$ are also generated in the case of $e_1[e_2]$  {\em ??=} $e_3$.
@@ -4565,6 +4577,8 @@ For any other valid operator $op$, a compound assignment of the form $v$ $op\cod
 \LMHash{}
 Evaluation of a compound assignment of the form $e_1?.v$ $op = e_2$ is equivalent to \code{((x) $=>$ x?.v = x.v $op$ $e_2$)($e_1$)} where $x$ is a variable that is not used in $e_2$. The static type of $e_1?.v$ $op = e_2$ is the static type of $e_1.v$ $op$ $e_2$. Exactly the same static warnings that would be caused by $e_1.v$ $op = e_2$ are also generated in the case of $e_1?.v$ $op = e_2$.
 
+% Buggy. Allows C?.v = e.
+
 \begin{grammar}
 {\bf compoundAssignmentOperator:}`*=';
       `/=';
@@ -5002,6 +5016,7 @@ A postfix expression of the form \code{$v$++}, where $v$ is an identifier, is eq
 
 \rationale{The above ensures that if $v$ is a field, the getter gets called exactly once. Likewise in the cases below. 
 }
+%what about e?.x++ 
 
 \LMHash{}
 A postfix expression of the form \code{$C.v$ ++} is equivalent to 
@@ -5625,6 +5640,14 @@ where \code{n0} is an identifier that does not occur anywhere in the program.
 \commentary{
 Note that in fact, using a  \CONST{} variable would give rise to a compile time error since \cd{n0.current} is not a constant expression.  
 }
+
+It is a static warning if the static type of $e$ does not have a member \cd{iterator}. It is a static warning if the static type of \cd{$e$.iterator} does not have a method \cd{moveNext}. It is a static warning if static return type of  \cd{$e$.iterator.moveNext()} is not assignable to the static type of \cd{id}.

[Paul Berry, 2015/06/12 18:28:09]

I don't think this is what we want:

1. It seems redundant to require that the static type of e has a member
"iterator", since the equivalent code above will have a static warning if it
doesn't.  However, if you are including this for completeness, then it is not
sufficient to require the static type of e to have a member "iterator".  We need
to require a *getter* called "iterator"; otherwise we won't catch the case where
the member "iterator" is an explicit setter that lacks a corresponding getter.

2. Requiring moveNext to be a method seems too broad.  The equivalent code above
allows moveNext to be a getter that returns a function, and the current vm and
dart2js implementations are consistent with this; so I think the static warnings
should permit moveNext to be a function-typed getter (or a getter whose type is
dynamic).

3. The static return type of moveNext needs to be be assignable to bool, since
in the equivalent code above, moveNext() is called in the condition of a while
loop.

4. There should be a static warning if moveNext has any required parameters.

5. There should be a static warning if the static type of e.iterator does not
have a getter called "current".

6. There should be a static warning if the static type of e.iterator.current is
not assignable to the static type of id.

As an alternative to spelling out all these cases, you might consider just
specifying that "for (finalConstVarOrType? id in e) s" has the same static
warnings as:

T n0 = e.iterator;
while (n0.moveNext()) {
  finalConstVarOrType? id = n0.current;
  s
}

where T is the static type of e.iterator.

+
+
+\commentary {
+One might have required that \cd{n0} had type \cd{Iterable$<T>$} where $T$ was the static type of \cd{id}. However, that would cause failure in checked mode if $e$ was merely emulating the  \cd{Iterable} interface. 
+}
+ 
  
 \subsubsection{Asynchronous For-in}
 \LMLabel{asynchronousFor-in}
@@ -6557,17 +6580,22 @@ An import directive $I$ may optionally include a namespace combinator clauses us
 Let $I$ be an import directive that refers to a URI via the string $s_1$. Evaluation of $I$  proceeds as follows:
 
 \LMHash{}
-If $I$ is a deferred import, no evaluation takes place. Instead, a mapping of the name of the prefix, $p$ to a {\em deferred prefix object} is added to the scope of $L$.
+If $I$ is a deferred import, no evaluation takes place. Instead, a mapping of the name of the prefix, $p$ to a {\em deferred prefix object} is added to the scope of the current library $L$.
 The deferred prefix object has the following methods:
 
 \begin{itemize}
 \item \code{loadLibrary}. This method returns a future $f$. When called, the method causes an immediate import $I'$ to be executed at some future time, where $I'$ is is derived from $I$ by eliding the word \DEFERRED{} and adding a \HIDE{} \code{loadLibrary}  combinator clause. When $I'$ executes without error, $f$ completes successfully. If $I'$ executes without error, we say that the call to \code{loadLibrary} has succeeded, otherwise we say the call has failed.
-\item  For every top level function $f$ named $id$ in $L$, a corresponding method named $id$ with the same signature as $f$. Calling the method results in a runtime error.
-\item For every top level getter $g$ named $id$ in $L$, a corresponding getter named $id$ with the same signature as $g$.  Calling the method results in a runtime error.
-\item For every top level setter $s$ named $id$ in $L$, a corresponding setter named $id$ with the same signature as $s$.  Calling the method results in a runtime error.
-\item For every type $T$ named $id$ in $L$, a corresponding getter named $id$ with return type \code{Type}.  Calling the method results in a runtime error.
+\item  For every top level function $f$ named $id$ in the imported library $B$, a corresponding method named $id$ with the same signature as $f$. Calling the method results in a runtime error.
+\item For every top level getter $g$ named $id$ in $B$, a corresponding getter named $id$ with the same signature as $g$.  Calling the method results in a runtime error.
+\item For every top level setter $s$ named $id$ in $B$, a corresponding setter named $id$ with the same signature as $s$.  Calling the method results in a runtime error.
+\item For every type $T$ named $id$ in $B$, a corresponding getter named $id$ with return type \code{Type}.  Calling the method results in a runtime error.
 \end{itemize}
 
+\rationale {
+The purpose of adding members of $B$ to $p$ is to ensure that any warnings  issued when using $p$ are correct, and no spurious warnings are generated.  In fact, at runtime we cannot add these members until $B$ is loaded; but any such invocations will fail at runtime as specified by virtue of being completely absent.
+}
+%But this is still a lie detectable by reflection. Probably revise so the type of p has these members but p does not.
+
 \LMHash{}
 After a call succeeds, the name $p$ is mapped to a non-deferred prefix object as described below. In addition, the prefix object also supports the \code{loadLibrary} method, and so it is possible to call \code{loadLibrary} again. If a call fails, nothing happens, and one again has the option to call \code{loadLibrary} again. Whether a repeated call to \code{loadLibrary} succeeds will vary as described below.
 
@@ -7270,7 +7298,7 @@ If a type $I$ includes an instance method named \CALL{}, and the type of \CALL{}
 %\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
+A function type $(T_1, \ldots T_{k}, [T_{k+1}  \ldots, T_{n+m}]) \rightarrow T$ is 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}
 \item Either