Implement messages in assert() in dev_compiler.

pkg/dev_compiler/lib/src/compiler/code_generator.dart

Index: pkg/dev_compiler/lib/src/compiler/code_generator.dart
diff --git a/pkg/dev_compiler/lib/src/compiler/code_generator.dart b/pkg/dev_compiler/lib/src/compiler/code_generator.dart
index b2f28d02be128a17d755fde38a578af25902e6ff..797972a28097473e0e3a8e60c6d82777294a2525 100644
--- a/pkg/dev_compiler/lib/src/compiler/code_generator.dart
+++ b/pkg/dev_compiler/lib/src/compiler/code_generator.dart
@@ -3819,9 +3819,15 @@ class CodeGenerator extends GeneralizingAstVisitor
       new JS.EmptyStatement();
 
   @override
-  JS.Statement visitAssertStatement(AssertStatement node) =>
-      // TODO(jmesserly): only emit in checked mode.
-      _callHelperStatement('assert(#);', _visit(node.condition));
+  JS.Statement visitAssertStatement(AssertStatement node) {
+    // TODO(jmesserly): only emit in checked mode.
+    if (node.message != null) {
+      return _callHelperStatement('assertMessage(#, () => #);',

[Jennifer Messerly, 2016/12/12 22:36:01]

i'd prefer this to be an optional parameter to dart.assert, rather than a second
runtime function.

(my thought process for generating readable JS is: what would a JS user and/or
library author do?)

so this would be 'assert(#, () => #)'

[Bob Nystrom, 2016/12/13 19:29:51]

Done. I wanted to distinguish between an explicit null message (which should
print "Assertion failed: null", not "Assertion failed" and no message. That
meant I couldn't do "!= null" later to decide which kind of error to show.

But I realize now that since the message is always thunked, I can check for null
because an explicit null message will show up as a thunk that returns null, not
a bare null.

+          [_visit(node.condition), _visit(node.message)]);
+    }
+
+    return _callHelperStatement('assert(#);', _visit(node.condition));
+  }
 
   @override
   JS.Statement visitReturnStatement(ReturnStatement node) {