Expression evaluation fails in top-level functions with "113 Expression compilation error"

[DanTup]

Someone reported this in flutter-dev recently but I wasn't able to repro. Today @escamoteur hit it and send me info into to repro. Seems quite simple; in a top level function calling evaluateInFrame with an argument from the function you get this error.

Request:

{
	"id": "534",
	"method": "evaluateInFrame",
	"params": {
		"expression": "urls",
		"frameIndex": 0,
		"isolateId": "isolates/849159470"
	}
}

Response:

{
	"jsonrpc": "2.0",
	"id": "534",
	"error": {
		"code": 113,
		"message": "Expression compilation error",
		"data": {
			"details": "NoSuchMethodError: The method '[]' was called on null.\nReceiver: null\nTried calling: [](\"result\")"
		}
	}
}

[DanTup]

It actually doesn't seem to matter what the expression is, providing a or test also fails with the same error.

[DanTup]

(cc @aam)

[DanTup]

@aam Did you fix this? I can't repro now in my integration tests nor manually :-)

[aam]

The proper fix for this landed in dart, but hasn't landed in flutter yet.
But while it's been landed we put a workaround #18657

[DanTup]

Ah, that explains it - thanks!

[DanTup]

@aam I was trying to implement global expression evaluation (so a user can evaluate expressions in the debug console when not paused), but I see the same issue:

"test"
113 Expression compilation error
1+1
113 Expression compilation error

Do you know if this will work once the "real" fix lands, or is it a different issue?

[aam]

Not sure. What does error.data field say? Are you able to reproduce this in observatory?

[DanTup]

Oops, I should've looked at the full response!

_buildExpressionEvaluationScope: invalid 'targetId' parameter: null

What should I pass as the target if I don't have a library/class/instance? In the debug console I don't really have any context (though I'm using the first spawned thread since I'm forced to provide an isolate - not ideal, but the best I could think of).

[aam]

I believe for this use case targetId should point to either a library or a class. That is needed because it gives context for name resolution of all symbols used in the expression.

[DanTup]

I don't really have a good reference to either in this context. Does targetting the rootLib of the first isolate seem like a reasonable thing to do?

@jacob314 you mentioned performing evaluations when not paused - what are you using for the target?

[aam]

I don't really have a good reference to either in this context. Does targetting the rootLib of the first isolate seem like a reasonable thing to do?

Not sure. As a user you have particular source code in front of you when you are evaluating an expression, right? It might be that you want to use current editor context for expression evaluation. It might be that you remember what was the context for the expression when user added it to Watch view.

[jacob314]

In IntelliJ we use the current editor context. If the current cursor position in the selected file is inside a class we use the selected class rather than just the library itself. That way static fields within a class are also in scope. Generally, there is no harm in using the class instead of the library if you know the right class as selecting the class will just add a few more useful names to the available scope.

[DanTup]

What's the best way to get a reference to the class in the debugger? I can get the Classes name from the Outline info; should I then enumerate the Isolates/Libraries/Classes to find a match or is there a better way?

[jacob314]

You should first determine the library that matches the source file and then enumerate the classes within that library.
It would be nice if the vm service protocol provided a helper to make this use case more convenient.

As far as isolate goes, you want the isolate that is running flutter code. To determine that on the IntelliJ side we listen for which isolate is registering ext.flutter vm service events and assume that is the flutter ui isolate.

[DanTup]

Perfect, thanks!

[DanTup]

Actually, this turns out to be complicated; because my debug adapter can be running in another process that doesn't know where the user is in the editor. We'd have to either send messages from the debugger back to the editor to ask for the location, or have the editor inform the debugger where the user is periodically.

I'm gonna put this on hold for now while I think more about it.

[aam]

I will close this issue marking it working-as-intended - due to #18678 (comment).

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.