fix to run against latest analyzer

fix to run against latest analyzer

hard part was dealing with the new for-each changes
the good news is the new for-each logic simplifes our await-for checking

R=leafp@google.com, rnystrom@google.com

Committed: https://github.com/dart-lang/dev_compiler/commit/d475c68b387194635c0ea07ed6d7ea1c022e8d78

[Jennifer Messerly, 2016-03-28 18:31:30]

jmesserly@google.com changed reviewers:
+ leafp@google.com, rnystrom@google.com

[Jennifer Messerly, 2016-03-28 18:31:31]

+Bob & Leaf since y'all have the most context on these Analyzer changes.

[Jennifer Messerly, 2016-03-28 18:33:17]

https://codereview.chromium.org/1840713003/diff/20001/lib/src/codegen/js_code...
File lib/src/codegen/js_codegen.dart (right):

https://codereview.chromium.org/1840713003/diff/20001/lib/src/codegen/js_code...
lib/src/codegen/js_codegen.dart:2343:
node.fields.variables.forEach(_emitModuleItem);
This is a small cleanup. It's actually what I originally started the CL for :)

I was trying to understand why static fields were going through the loader, that
seemed like a no-op. The answer is yes, it's a no-op :)

[Leaf, 2016-03-28 20:24:49]

lgtm, with question about dart:html

https://codereview.chromium.org/1840713003/diff/20001/tool/sdk_expected_error...
File tool/sdk_expected_errors.txt (left):

https://codereview.chromium.org/1840713003/diff/20001/tool/sdk_expected_error...
tool/sdk_expected_errors.txt:247: severe: [AnalyzerMessage] The setter 'href' is
not defined for the class 'Element'. (dart:html, line 172, col 25)
Did something happen to dart:html in this roll?  It looks like all of the error
messages went away, which seems suspicious... :)

[Bob Nystrom, 2016-03-28 21:05:38]

One question, and I wouldn't say I understood much of the code, but LGTM
otherwise.

https://codereview.chromium.org/1840713003/diff/20001/tool/sdk_expected_error...
File tool/sdk_expected_errors.txt (right):

https://codereview.chromium.org/1840713003/diff/20001/tool/sdk_expected_error...
tool/sdk_expected_errors.txt:120: warning: [DOWN_CAST_COMPOSITE] Unsound
implicit cast from dynamic to E (dart:collection/hash_set.dart, line 128, col
12)
Shouldn't this be DYNAMIC_CAST now? Did I do something wrong in the error
generation?

[Leaf, 2016-03-28 21:09:09]

https://codereview.chromium.org/1840713003/diff/20001/tool/sdk_expected_error...
File tool/sdk_expected_errors.txt (right):

https://codereview.chromium.org/1840713003/diff/20001/tool/sdk_expected_error...
tool/sdk_expected_errors.txt:120: warning: [DOWN_CAST_COMPOSITE] Unsound
implicit cast from dynamic to E (dart:collection/hash_set.dart, line 128, col
12)
On 2016/03/28 21:05:37, Bob Nystrom wrote:
> Shouldn't this be DYNAMIC_CAST now? Did I do something wrong in the error
> generation?

I don't think so.  E is potentially a composite type, so I think we treat this
as a down cast composite.

[Bob Nystrom, 2016-03-28 21:11:10]

On 2016/03/28 21:09:09, Leaf wrote:
>
https://codereview.chromium.org/1840713003/diff/20001/tool/sdk_expected_error...
> File tool/sdk_expected_errors.txt (right):
> 
>
https://codereview.chromium.org/1840713003/diff/20001/tool/sdk_expected_error...
> tool/sdk_expected_errors.txt:120: warning: [DOWN_CAST_COMPOSITE] Unsound
> implicit cast from dynamic to E (dart:collection/hash_set.dart, line 128, col
> 12)
> On 2016/03/28 21:05:37, Bob Nystrom wrote:
> > Shouldn't this be DYNAMIC_CAST now? Did I do something wrong in the error
> > generation?
> 
> I don't think so.  E is potentially a composite type, so I think we treat this
> as a down cast composite.

Ah, got it. Thanks!

[Jennifer Messerly, 2016-03-28 21:22:09]

Thanks guys!

https://codereview.chromium.org/1840713003/diff/20001/tool/sdk_expected_error...
File tool/sdk_expected_errors.txt (left):

https://codereview.chromium.org/1840713003/diff/20001/tool/sdk_expected_error...
tool/sdk_expected_errors.txt:247: severe: [AnalyzerMessage] The setter 'href' is
not defined for the class 'Element'. (dart:html, line 172, col 25)
On 2016/03/28 20:24:49, Leaf wrote:
> Did something happen to dart:html in this roll?  It looks like all of the
error
> messages went away, which seems suspicious... :)

funny that. So what happens, is apparently we now run some node.js tests, and
they overwrite(!) our SDK error log. I usually kill the presubmit before they
get there, because I didn't know that step was lurking at the end, after the
format :)

anyway would be good to fix, maybe I can restore this in a follow up CL

[Jennifer Messerly, 2016-03-28 21:22:41]

Description was changed from

==========
fix to run against latest analyzer

hard part was dealing with the new for-each changes
the good news is the new for-each logic simplifes our await-for checking
==========

to

==========
fix to run against latest analyzer

hard part was dealing with the new for-each changes
the good news is the new for-each logic simplifes our await-for checking

R=leafp@google.com, rnystrom@google.com

Committed:
https://github.com/dart-lang/dev_compiler/commit/d475c68b387194635c0ea07ed6d7...
==========

[Jennifer Messerly, 2016-03-28 21:22:43]

Committed patchset #2 (id:20001) manually as
d475c68b387194635c0ea07ed6d7ea1c022e8d78 (presubmit successful).