Change how we deal with manual inlining of argument error and NSM when propagating types. This chan…

tests/compiler/dart2js/is_inference_test.dart

Index: tests/compiler/dart2js/is_inference_test.dart
===================================================================
--- tests/compiler/dart2js/is_inference_test.dart	(revision 23949)
+++ tests/compiler/dart2js/is_inference_test.dart	(working copy)
@@ -7,6 +7,8 @@
 
 const String TEST_IF = r"""
 test(param) {
+  // Ensure a String+ is in the system.
+  print('foo');

[kasperl, 2013/06/14 06:19:08]

So printing foo is enough to ensure that String + is in the system? Is there a
more obvious way actually involving + (in a helper method perhaps)?

If you want to keep this, I'd go for something like:

  print('Printing this ensures that String+ is in the system.');

and do that in all the other places where you print.

[ngeoffray, 2013/06/14 06:58:34]

Yes, the [: param + 53 :] expression line 15 does not know what param is and
could hit String+ or num+.
The helper method might be inlined and any use of a + in it optimized. It is a
bit more complicated if we don't want the helper to be a no-op.
Done.

   if (param is int) {
     param = param + 42;
   }
@@ -16,6 +18,7 @@
 
 const String TEST_IF_ELSE = r"""
 test(param) {
+  print('foo');
   if (param is int) {
     param = param + 42;
   } else {
@@ -27,6 +30,7 @@
 
 const String TEST_IF_RETURN = r"""
 test(param) {
+  print('foo');
   if (param is int) {
     return param + 42;
   }
@@ -36,6 +40,7 @@
 
 const String TEST_IF_NOT_ELSE = r"""
 test(param) {
+  print('foo');
   if (param is !int) {
     param = param + 53;
   } else {
@@ -47,6 +52,7 @@
 
 const String TEST_IF_NOT_RETURN = r"""
 test(param) {
+  print('foo');
   if (param is !int) return param + 53;
   return param + 42;
 }
@@ -54,6 +60,7 @@
 
 const String TEST_IF_NOT_ELSE_RETURN = r"""
 test(param) {
+  print('foo');
   if (param is !int) {
     return param + 53;
   } else {