Tests named Foo<class> cannot be debugged from VSCode

[timsneath]

Describe the bug
When running on Windows, the following test cannot be debugged from within VScode (by clicking the inline annotation):

  test('Find interfaces returns sane results with IEnumerable<class>', () {
    final winTypeDef = MetadataStore.getMetadataForType(
        'Windows.Media.Playback.PlaybackMediaMarkerSequence')!;

    final interfaces = winTypeDef.interfaces;
    expect(interfaces.length, equals(2));

    expect(interfaces.first.name, endsWith('IPlaybackMediaMarkerSequence'));
    expect(interfaces.last.typeSpec?.typeArg?.name,
        endsWith('PlaybackMediaMarker'));
  });

The debug console prints:

Connecting to VM Service at http://127.0.0.1:52148/GUWXcX9eYY8=/ws
No tests match regular expression "^Find interfaces returns sane results with IEnumerable^<class^>( \(variant: .*\))?$".
Exited (79)

When I rename the test to

  test('Find interfaces returns sane results with IEnumerable class ', () {
  ...
  });

the test is debugged.

For clarity, I'm executing the test by pressing the Debug button here:

Please complete the following information:

• Operating System and version: Windows 10.0.19044.1806
• VS Code version: 1.68.1
• Dart extension version: 3.42.1
• Dart/Flutter SDK version: from Flutter 3.1.0-9.0.pre

[DanTup]

Thanks! I thought this would've been fixed by #3863 but I'll do some testing. There's an open issue about switching to a new way of running individual tests using their line numbers (#4021) which would also avoid needing to escape these names on the CLI (as well as handle some cases where the tests are in functions where we can't statically build their full names).

[DanTup]

Turns out escaping < and > when they're not after quotes fails. This doesn't seem to match what's described on https://ss64.com/nt/syntax-esc.html but escaping only after quotes seems to handle both this case and the original case in #3863.

I've opened #4046 as a reminder to ensure the new SDK DAPs handle both cases the same so neither issue returns as we migrate (although the new integration tests will also catch this).