Add optional message argument to assert statements in the VM.

sdk/lib/core/errors.dart

Index: sdk/lib/core/errors.dart
diff --git a/sdk/lib/core/errors.dart b/sdk/lib/core/errors.dart
index 0e99b0b271ce48375f613c2fc9522aad6d0e5019..f8b55b17cb014fa6472043beb8a824eef739b758 100644
--- a/sdk/lib/core/errors.dart
+++ b/sdk/lib/core/errors.dart
@@ -96,6 +96,9 @@ class Error {
  * Error thrown by the runtime system when an assert statement fails.
  */
 class AssertionError extends Error {
+  /** Message describing the assertion error. */
+  final Object message;

[sra1, 2015/09/02 18:00:27]

1. Is the intention to also give TypeError a message field?

2. This is a breaking change for anyone who implements AssertionError or
TypeError as they have to now implement get:message.  I'm not bothered by that
but I would like some clarity on what aTypeError.message is expected to return. 
The same as toString()?

[Lasse Reichstein Nielsen, 2015/09/03 07:42:04]

No, but it's an inadvertent consequence of making AssertionError have a field
and TypeError being defined as subclassing AssertionError.
I.e., I'm aware of it, and didn't find a way to avoid it (short of not making
TypeError an AssertionError).
For the record, it is *not* a breaking change.
No existing code will stop working.

It will make some libraries be outdated and cause warnings,
and if you start using the "message" field on objects from those libraries, your
code will not work, but that won't happen by itself.
Probably null since you don't have a way to specify a message for type
assertions.
Which suggests that making the message public might not be such a great idea
anyway. That, or making TypeError an AssertionError was the mistake.

+  AssertionError([this.message]);
 }
 
 /**