Evaluation results in different variable

[FMorschel]

Env: Dart 3.8.0-edge.a14aa2612c0e738aaa5ba2f6b84986710f947eee - Windows 11 x64

Steps:

• Clone https://github.com/FMorschel/sdk/tree/auto-complete-instance branch
• Place a breakpoint in pkg\analysis_server\lib\src\handler\legacy\completion_get_suggestions2.dart at line 241
• Run the new test at pkg\analysis_server\test\services\completion\dart\location\dart_doc_test.dart (failing but not the point)

See the type of completionRequest:

See the hover result:

Not a subclass of List:

Here is the watch:

At this point we can see that it thinks completionRequest is actually suggestions, but another weird thing I found was when I tried evaluating the line 241 (completionRequest.replacementOffset) to see why it was failing, on debug console. I'm unsure of the LegacyAnalysisServer.handleRequest but maybe evaluation still uses legacy. This is the stacktrace but I guess this unrelated to the actual problem:

Unhandled exception:
NoSuchMethodError: Class 'List<CompletionSuggestion>' has no instance getter 'replacementOffset'.
Receiver: Instance(length:1) of '_GrowableList'
Tried calling: replacementOffset
#0      Object.noSuchMethod (dart:core-patch/object_patch.dart:38:5)
#1      CompletionGetSuggestions2Handler.Eval ()
#2      CompletionGetSuggestions2Handler.handle.<anonymous closure>.<anonymous closure> (package:analysis_server/src/handler/legacy/completion_get_suggestions2.dart:241:31)
#3      OperationPerformanceImpl.run (package:analyzer/src/util/performance/operation_performance.dart:155:23)
#4      CompletionGetSuggestions2Handler.handle.<anonymous closure> (package:analysis_server/src/handler/legacy/completion_get_suggestions2.dart:238:19)
< asynchronous suspension>
#5      OperationPerformanceImpl.runAsync (package:analyzer/src/util/performance/operation_performance.dart:174:14)
< asynchronous suspension>
#6      CompletionGetSuggestions2Handler.handle (package:analysis_server/src/handler/legacy/completion_get_suggestions2.dart:141:5)
< asynchronous suspension>
#7      LegacyAnalysisServer.handleRequest.<anonymous closure>.<anonymous closure> (package:analysis_server/src/legacy_analysis_server.dart:643:13)
< asynchronous suspension>
#8      OperationPerformanceImpl.runAsync (package:analyzer/src/util/performance/operation_performance.dart:174:14)
< asynchronous suspension>
#9      LegacyAnalysisServer.handleRequest.<anonymous closure> (package:analysis_server/src/legacy_analysis_server.dart:623:9)
< asynchronous suspension>

CC @DanTup.

[FMorschel]

All variables at this point are swapped and I think because of # I can't evaluate _#wc0#formal (even though I'm unsure where this is from since there is no such thing on the whole file)

[DanTup]

@bkonyi any idea what's going on here? It seems like evaluating the names of variables is returning the wrong variables (it's like they're being looked up from a list with the wrong indexes).

The "Locals" section in the screenshot above is being taken from the frame variables (which are correct), but the "Watch" section is evaluations of the strings on the left, and they're returning adjacent(?) values. This seems very weird, but I don't know how these are looked up internally.

[FMorschel]

Wildcard variables seem to be the problem here:

Edit: I don't think they should appear on the variables list since they don't bind anymore, right? Only top-level things with this name should show up.

[DanTup]

Wildcard variables seem to be the problem here:

Aaah, well spotted! I can indeed repro with some simpler code like this:

void main() {
  var x = (a, _, b) {
    print(a);
    print(b);
  };

  x(1, 2, 3);
}

Edit: I don't think they should appear on the variables list since they don't bind anymore, right?

Yeah, I agree. I'm not sure at what point they should be filtered out though (maybe @bkonyi or @derekxu16 may know if this should be in DAP, or if they shouldn't be in the frames variable list?).

[bkonyi]

We definitely shouldn't be reporting anything for wildcard variables, so this is likely a bug in the VM.

[kallentu]

Found the bug in the CFE, making a quick fix.

[FMorschel]

This also happens on stable so we'd probably also need to prepare a CL for CP.

[FMorschel]

Not related to the meaning but another issue about wildcard variables:

• strict_top_level_inference is triggered for wildcard variables #60136