Remove eval error message on async frames

[annagrin]

Closes: #2057

[elliette]

I think this would make sense as an enhanced enum, with methods such as toDisplayName / fromDisplayName so that we don't have to do the String matching (eg type.startsWith('${EvaluationErrorKind.compilation}'))

[annagrin]

I believe it is not really possible to express what I wanted here in dart, which would be something like:

enum EvaluationErrorKind {
  compilation = 'CompilationError',
  reference = 'ReferenceError',
 ...
}

So i'll have to resort to the usual "define a bunch of const strings and add comments on function parameters" that we use everywhere:) I'll do that to match other use cases, but I don't like losing the type safety of course.

[annagrin]

done!

[elliette]

I wonder if we could test this by providing a fake debugger (like we're providing a "real" debugger here)

webdev/dwds/test/expression_evaluator_test.dart

Lines 50 to 56 in 0a2804b

	final debugger = await Debugger.create(
	webkitDebugger,
	(_, __) {},
	locations,
	skipLists,
	root,
	);

which returns null for jsFrameForIndex.

I think ideally we need to add better support for unit testing and mocks though: #1643

[annagrin]

I wonder if we could test this by providing a fake debugger (like we're providing a "real" debugger here)

webdev/dwds/test/expression_evaluator_test.dart

Lines 50 to 56 in 0a2804b

	final debugger = await Debugger.create(
	webkitDebugger,
	(_, __) {},
	locations,
	skipLists,
	root,
	);

which returns null for jsFrameForIndex.
I think ideally we need to add better support for unit testing and mocks though: #1643

Many other things will not work in the fake debugger (like location mapping etc) so I think we can do it as part of work for adding more unit tests and mocks. I'll think about it in the background as well, but for now I've found a way to test a real scenario - I figured out the way to hit the async code consistently, and it is matching flutter tools scenario (the code I keep hitting there when pausing is part of registering extensions machinery).

[annagrin]

I wonder if we could test this by providing a fake debugger (like we're providing a "real" debugger here)

webdev/dwds/test/expression_evaluator_test.dart

Lines 50 to 56 in 0a2804b

	final debugger = await Debugger.create(
	webkitDebugger,
	(_, __) {},
	locations,
	skipLists,
	root,
	);

which returns null for jsFrameForIndex.
I think ideally we need to add better support for unit testing and mocks though: #1643

Many other things will not work in the fake debugger (like location mapping etc) so I think we can do it as part of work for adding more unit tests and mocks. I'll think about it in the background as well, but for now I've found a way to test a real scenario - I figured out the way to hit the async code consistently, and it is matching flutter tools scenario (the code I keep hitting there when pausing is part of registering extensions machinery).

Update: added a test in expression_evaluator_test.dart that produces an async frame error. I does not test for the absence of a warning though, as the warning comes from chrome_proxy_service.dart. The previously added evaluation test covers that though.