[XL] Change in dart/sdk[main]: Add test for `void`-expressions around operators.

0 views
Skip to first unread message

Lasse Nielsen (Gerrit)

unread,
Mar 9, 2026, 8:18:15 AM (17 hours ago) Mar 9
to Erik Ernst, Commit Queue, rev...@dartlang.org
Attention needed from Erik Ernst

Lasse Nielsen added 1 comment

Patchset-level comments
File-level comment, Patchset 3 (Latest):
Lasse Nielsen . resolved

Does this test look correct for the currently specified behavior?

Open in Gerrit

Related details

Attention is currently required from:
  • Erik Ernst
Submit Requirements:
  • requirement is not satisfiedCode-Owners
  • requirement is not satisfiedCode-Review
  • requirement is not satisfiedReview-Enforcement
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
Gerrit-MessageType: comment
Gerrit-Project: sdk
Gerrit-Branch: main
Gerrit-Change-Id: I74200bf617b8ad1b04badc8d7cef6de0d4ee0204
Gerrit-Change-Number: 486182
Gerrit-PatchSet: 3
Gerrit-Owner: Lasse Nielsen <l...@google.com>
Gerrit-Reviewer: Erik Ernst <eer...@google.com>
Gerrit-Reviewer: Lasse Nielsen <l...@google.com>
Gerrit-Attention: Erik Ernst <eer...@google.com>
Gerrit-Comment-Date: Mon, 09 Mar 2026 12:18:11 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
unsatisfied_requirement
open
diffy

Erik Ernst (Gerrit)

unread,
Mar 9, 2026, 10:49:02 AM (15 hours ago) Mar 9
to Lasse Nielsen, Commit Queue, rev...@dartlang.org
Attention needed from Lasse Nielsen

Erik Ernst added 25 comments

Patchset-level comments
Erik Ernst . resolved

Thanks for digging into this topic, this is very useful!

I do think, though, that we should clarify the treatment of user-definable operators (and even `yield`) in order to ensure that we have a consistent design. See also https://github.com/dart-lang/language/issues/4659 and https://github.com/dart-lang/language/issues/4660.

File tests/language/void/void_operand_error_test.dart
Line 72, Patchset 3 (Latest): o + v;
Erik Ernst . unresolved

I'd expect an operand to be treated like the actual argument to a member invocation that it is semantically. So this would not be an error. Similarly for the other cases below.

The allowlist in the language specification does not mention operators other than `[]` and `[]=`. We probably forgot about the situation where the formal parameter of an operator has type `void`.

However, the CFE reports these errors and the analyzer does not, which means that we need to change implementations no matter what. Also, making `o + print('')` a non-error would be a non-breaking change for the CFE (and a non-change for the analyzer).

Do you see any reason why we would not treat all actual arguments the same?

Line 142, Patchset 3 (Latest): o[v] += v;
Erik Ernst . unresolved

With the proposed uniform treatment of actual arguments, we wouldn't expect an error here.

Line 157, Patchset 3 (Latest): no?[v] += v;
Erik Ernst . unresolved

No error if treating all actual arguments uniformly.

Line 167, Patchset 3 (Latest): // and operand of `[]` or `[]=` (or both).
Erik Ernst . unresolved

Typo: 'an' operand.

Line 171, Patchset 3 (Latest): o..[v] += v;
Erik Ernst . unresolved

No error if treating actual arguments uniformly.

Line 181, Patchset 3 (Latest): no?..[v] += v;
Erik Ernst . unresolved

No error if treating actual arguments uniformly.

Line 228, Patchset 3 (Latest): S.property += v; // Argument to `C.operator +`, not `[]` or `[]=`.
Erik Ernst . unresolved

No error if treating actual arguments uniformly.

Line 250, Patchset 3 (Latest): topProperty += v; // Argument to `C.operator +`, not `[]` or `[]=`.
Erik Ernst . unresolved

No error if treating actual arguments uniformly.

Line 301, Patchset 3 (Latest): o + v;
Erik Ernst . unresolved

These would be similar to the non-generic variants, no errors if actual arguments are treated uniformly.

Line 368, Patchset 3 (Latest): o[v] += v; // Argument to G.operator+, not []=.
Erik Ernst . unresolved

No error if uniform.

Line 381, Patchset 3 (Latest): no?[v] += v; // Argument to G.operator+, not []=.
Erik Ernst . unresolved

No error if uniform.

Line 394, Patchset 3 (Latest): o..[v] += v;
Erik Ernst . unresolved

No error if uniform.

Line 404, Patchset 3 (Latest): no?..[v] += v;
Erik Ernst . unresolved

No error if uniform.

Line 460, Patchset 3 (Latest): o + v;
Erik Ernst . unresolved

No error if uniform.

Line 531, Patchset 3 (Latest): o[v] += v;
Erik Ernst . unresolved

No error if uniform.

Line 544, Patchset 3 (Latest): no?[v] += v;
Erik Ernst . unresolved

No error if uniform.

Line 558, Patchset 3 (Latest): o..[v] += v;
Erik Ernst . unresolved

No error if uniform.

Line 568, Patchset 3 (Latest): no?..[v] += v;
Erik Ernst . unresolved

No error if uniform.

Line 624, Patchset 3 (Latest): o + v;
Erik Ernst . unresolved

No error if uniform.

Line 695, Patchset 3 (Latest): o[v] += v;
Erik Ernst . unresolved

No error if uniform.

Line 708, Patchset 3 (Latest): no?[v] += v;
Erik Ernst . unresolved

No error if uniform.

Line 721, Patchset 3 (Latest): o..[v] += v;
Erik Ernst . unresolved

No error if uniform.

Line 731, Patchset 3 (Latest): no?..[v] += v;
Erik Ernst . unresolved

No error if uniform.

Line 933, Patchset 3 (Latest): // No yielding `void`, even if the element type is `void`.
Erik Ernst . unresolved

Great catch!

But why would we report an error for yielding void to void, considering that we're happy returning void to void? I created #4660 to clarify this.

Open in Gerrit

Related details

Attention is currently required from:
  • Lasse Nielsen
Submit Requirements:
  • requirement is not satisfiedCode-Owners
  • requirement is not satisfiedCode-Review
  • requirement is not satisfiedReview-Enforcement
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
Gerrit-MessageType: comment
Gerrit-Project: sdk
Gerrit-Branch: main
Gerrit-Change-Id: I74200bf617b8ad1b04badc8d7cef6de0d4ee0204
Gerrit-Change-Number: 486182
Gerrit-PatchSet: 3
Gerrit-Owner: Lasse Nielsen <l...@google.com>
Gerrit-Reviewer: Erik Ernst <eer...@google.com>
Gerrit-Reviewer: Lasse Nielsen <l...@google.com>
Gerrit-Attention: Lasse Nielsen <l...@google.com>
Gerrit-Comment-Date: Mon, 09 Mar 2026 14:48:57 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
unsatisfied_requirement
open
diffy
Reply all
Reply to author
Forward
0 new messages