Skip to content

Conversation

@sgrekhov
Copy link
Contributor

No description provided.

@sgrekhov sgrekhov assigned sgrekhov and unassigned sgrekhov Oct 31, 2025
@sgrekhov sgrekhov requested review from eernstg and nshahan October 31, 2025 10:58
Copy link
Member

@eernstg eernstg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, awaiting further input.

@sgrekhov sgrekhov requested a review from eernstg October 31, 2025 12:30
Copy link
Member

@eernstg eernstg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, awaiting further input.

Copy link

@nshahan nshahan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One question for you but otherwise LGTM.

Comment on lines +119 to +122
Expect.equals("null", xRef1.valueAsString);
final xRef2 =
await service.evaluateInFrame(isolateId, 0, 'this._x') as InstanceRef;
Expect.equals("null", xRef2.valueAsString);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is confusing to me that we expect _x and this._x to both be null at this time. Why?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the current behaviour of

class C {
  String x;
  C(this.x);
}

x is null at this step. Therefore, I believe, that in this test _x also should be null.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the current location in code is the initializer list (we could add an initializer list, or we might have stopped at a breakpoint "in the initializer list" even though it's empty, which could be the way the VM sees it) then x would denote the parameter. In contrast, at any location with access to this, including the body of the constructor (if any), x would denote the instance variable, and so would this.x.

The same would be true with _x.

If the current position in code is the initializer list it might still be possible to access the instance variables of the enclosing object using terms like this.x or this._x. The language doesn't allow us to do that, but the debugger might.

So I've argued that we should at least know how it's supposed to work, and preferably look at the treatment of both the parameter and the instance variable in situations where it is the intention that both can be viewed and possibly modified.

Copy link
Member

@eernstg eernstg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Send an unsent comment.)

@eernstg eernstg merged commit ba6bf83 into dart-lang:master Nov 5, 2025
2 checks passed
copybara-service bot pushed a commit to dart-lang/sdk that referenced this pull request Nov 7, 2025
2025-11-05 sgrekhov22@gmail.com dart-lang/co19#3330. Add static extensions tests. Part 1. (dart-lang/co19#3381)
2025-11-05 sgrekhov22@gmail.com dart-lang/co19#3203. Add tests for private named parameters (dart-lang/co19#3377)
2025-11-05 sgrekhov22@gmail.com dart-lang/co19#3203. Add VM - CFE interaction tests for primary initializer scope (dart-lang/co19#3359)

R=athom@google.com, eernst@google.com

Cq-Include-Trybots: luci.dart.try:analyzer-linux-release-try,dart2js-minified-linux-d8-try
Change-Id: Ibc9148c6d03bbc0b1f89ec5ad1e36e3171965779
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/460280
Auto-Submit: Sergey Grekhov <sgrekhov22@gmail.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants