Negative tests are broken by design.

The issue with negative tests is that test.py doesn't know if they are supposed to result in a compile-time error, runtime-error, checked-error, etc.

It is not possible to say if the analyzer is expected to print errors/warnings on a negative test or not. Consider the following negative test:

  tests/language/foobar_negative_test.dart
  main() {
    var x = null;
    x.foo();
  }

In that case, the none-vm and dart2js-d8 configurations will result in a runtime error, but the analyzer doesn't print errors/warnings and that's fine.

Because it's not possible to determine what the analyzer is expected to do on a negative test, we ignore the fact that it is a negative test and treat it as a normal test (i.e. for --compiler=dartanalyzer).

cc @ricowind.
Set owner to @mkustermann.
Added Invalid label.

Reopening as a test problem.

cc @mkustermann.
cc @peter-ahe-google.
cc @kasperl.
Removed the owner.
Removed Area-Tools label.
Added Area-Test, Triaged labels.

@bwilkerson @eernstg @whesse @leafpetersen

If a negative test is causing problems, I normally try to identify the original author and send them a CL to convert it to a multi-test. In multi-tests you can add information about how the test should fail.

Apologies - I just wanted to make the comment in here, about negative tests not working with analyze-only runs, available to the people working on the new issue #28664, which I could have done better by putting this issue number there. This particular issue can remain closed.

The current status of this issue is that the negative tests bad_initializer[1,2]_negative_test are marked as failing in all the status files for analyzer-only or compiler runs. Those lines should have this issue number added. Only if we decide that these failure lines in the status files are unacceptable, would we need to rewrite these as multitests.