Report a compile-time error when an expression of type `void` is used

[eernstg]

An expression of type void cannot be used, unless it occurs in a situation which is specifically allow-listed.

The language test $SDK/tests/language/void/void_type_usage_test.dart is testing that these compile-time errors occur. This test used to have some faults (in particular, it was a multi test that used some labels more than once, which allowed some missing compile-time errors to go undetected).

The test is migrated to use the new test expectation syntax in https://dart-review.googlesource.com/c/sdk/+/350921 (that is // ^^^ to define the location and then // [cfe] ... and/or // [analyzer] ... to specify the expected error message).

With this test update, about 130 missing compile-time error failures exist with the analyzer and similarly for the common front end. This issue exists to indicate that those error messages should be emitted.

This issue awaits a breaking change process.

[Edit: This is not a breaking change, there were only a couple of test failures. Removing the 'status-blocked' label.]

Subtasks:

• [cfe] Report a compile-time error when an expression of type void is used #54891

[eernstg]

https://dart-review.googlesource.com/c/sdk/+/350921 has now been updated such that there are as few failures as possible.

In particular, many test failures were eliminated by relaxing the expected error messages. There is no more an expectation that all errors caused by a non-allowlisted usage of an expression of type void gives rise to a specific error message (that is, COMPILE_TIME_ERROR.USE_OF_VOID_RESULT from the analyzer, and This expression has type 'void' and can't be used. from the front end, which is the typical response). Instead, the error message which is actually emitted is accepted (they are all reasonable). So if there is a compile-time error at all then that test succeeds (but it is still necessary to change the test if a tool starts emitting some other message for the given situation, it's not specified as unspecified).

Next, many test failures were caused by a bug that I introduced when I changed the test from a multi-test to a test that uses the "// ^^^" style expectations: The expression of type void was in some cases a local variable x, and that local variable would soon get promoted from void to some other type (typically Object?). Hence, there were no void related error messages when x was used. This bug might have created the impression (during the past few days) that both the analyzer and the CFE failed to report an error in a large number of situations involving void expressions, and that isn't true, that was my bug. ;-)

With those two things in place, the resulting test only fails in a handful of cases, and only with the CFE.

The language team will probably discuss this topic on Wednesday, but it is probably not going to be a breaking change after all.

[eernstg]

https://dart-review.googlesource.com/c/sdk/+/350921 has landed.