Support setting breakpoints inside dart SDK libraries

[annagrin]

Currently setting breakpoints inside the SDK libraries is not supported. The missing pieces:

• Figure out how to resolve dart: uris without depending on package:_fe_analyzer_shared See: https://github.com/dart-lang/webdev/issues/1575

• Save SDK metadata during compilation so dwds can read it (used for mapping of .dart files to their libraries and server paths in dwds) See: https://github.com/dart-lang/webdev/issues/1290 (part of) Also, a question - will SDK metadata have enough information to address the previous item as well? If not, is it possible to add this information to metadata?

• Pass correct SDK to dwds in flutter tools See: https://github.com/flutter/flutter/issues/101639 See: https://github.com/dart-lang/webdev/issues/1579

[annagrin]

Some questions - looks that in order to support breakpoints inside dart SDK files, dwds needs information that is currently contained in both libraries spec and debug metadata produced by the compiler.

• patches included in the libraries for dev_compiler scenario (libraries.spec)
• all dart files included in every SDK library and their paths, relative to the SDK directory (metadata)

@johnniwinther @nshahan is the information about patches accessible to dev compiler, so we can add it to the metadata? If it is possible, we might avoid creating special API for reading libraries spec.

[nshahan]

Please excuse me if this is already being discussed elsewhere but I recall that we have purposely black boxed the Dart SDK libraries so that you can't step into them and stack frames are collapsed into a single Dart SDK line from within DartDevTool. We will need to undo that somewhere and should probably still provide the black boxing as an option. I think in the past users have asked for this to avoid having their stacks filled with SDK frames.

is the information about patches accessible to dev compiler, so we can add it to the metadata? If it is possible, we might avoid creating special API for reading libraries spec.

I haven't looked into this too much but AFAIK from the perspective of DDC a patch file is applied and an AST is provided with source mapping as if the patch file lines were part of the original file and there isn't any reference to the original patch file. @johnniwinther can correct me if the process is different though.

[johnniwinther]

@nshahan Each Member has its own fileUri property. If the member (body) is defined in a patch file, the fileUri would hold this. There is no direct representation of the patch files within the AST.

[annagrin]

Please excuse me if this is already being discussed elsewhere but I recall that we have purposely black boxed the Dart SDK libraries so that you can't step into them and stack frames are collapsed into a single Dart SDK line from within DartDevTool.

We can currently step through and put breakpoints in dart SDK files and patches in VSCode for non-web platforms (need to select "Debug my code+packages+SDK" on the bottom bar). We don't currently support it on the web (so I created this issue to investigate what needs to be done for that).

[nshahan]

Each Member has its own fileUri property. If the member (body) is defined in a patch file, the fileUri would hold this. There is no direct representation of the patch files within the AST.

Thanks, that makes a lot of sense. @annagrin When we return to the module symbol data work we will probably need to update our collection of the files that make up a library. IIRC I was collecting the source file and parts from the library node but that wouldn't include any patch files.