Change most specified warnings to errors

[eernstg]

Cf. dart-lang/sdk#36127 and dart-lang/sdk#36126, the language specification specifies a few compile-time warnings:

• It is a static warning if the return type of a user-declared operator []= is explicitly declared and not void. (E)
• It is a static warning if a setter declares a return type other than void. (E)
• It is a static warning if a class has a setter named v= with argument type T and a getter named v with return type S, and S may not be assigned to T. (E)
• It is a static warning if an overriding method declaration declares a different default value for a parameter. (W)
• A switch statement may yield static warnings for various non-exhaustive lists of cases. (W)
• It is a static warning to import two different libraries with the same name unless their name is the empty string. (E)

However, the treatment of these warnings has been inconsistent for a long time.

The situations marked '(E)' are currently flagged as errors by the analyzer, and '(W)' is flagged as a warning. Given that the analyzer has flagged these situations as errors for a long time, we have the option to specify them as errors without breaking existing code.

This issue serves to discuss and clarify this situation.

Here is a concrete proposal: Change the specification to specify as errors those situations that are currently flagged as errors, as indicated above.

The treatment of the getter/setter type conflict is specified for null-safety, so it will be an error soon anyway, and similarly for the switch cases.

The examples in dart-lang/sdk#36127 would be adjusted and added as language tests.

@lrhn, @munificent, @leafpetersen, WDYT?

[lrhn]

I agree with making the (E) ones errors.

I still want to make the "different default value" not a warning at all. If it's not an error, then it's not a problem. People who wants the warning can still get it from the analyzer as a lint, if they want to, but then they also have a way avoid it. They can't avoid spec-mandated warnings.

The switch warning on incomplete enums is probably fine as a warning (but I'd prefer to make it non-spec mandated and leave it up to the analyzer, and try to avoid warnings in the spec).

[munificent]

I agree with making the (E) ones errors.

Me too.

[eernstg]

@leafpetersen, @natebosch, @jakemac53, @stereotype441, do you wish to speak up against making the '(E)' cases errors in the spec?

[stereotype441]

Making the '(E)' cases errors SGTM.

[leafpetersen]

LGTM.

[eernstg]

Cf. #1083.

[natebosch]

It is a static warning to import two different libraries with the same name unless their name is the empty string.

I guess this just must not come up in practice, but I don't know if I was aware this was a warning or error. What is the reasoning for this?