Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Macros: Add a way to obtain the StackTrace responsible for generating a code. #56916

Open
rrousselGit opened this issue Oct 18, 2024 · 3 comments
Labels
area-pkg Used for miscellaneous pkg/ packages not associated with specific area- teams. feature-macros Implementation of the macros feature P2 A bug or feature request we're likely to work on pkg-macros The experimental package:_macros library type-enhancement A request for a change that isn't a bug

Comments

@rrousselGit
Copy link

Hello!

Problem

When using code-generators, one challenge is: It's difficult to know what line was responsible for the generation of a piece of code.

Code-generators can become quite complex. It can take a lot of time to find exactly which line was responsible for generating a specific code.

Proposal

It would be interesting to have a "jump to the macro code that generated this line".
Since macros don't actually write to the file system but rather use some virtual file ; we could use this as an opportunity to store extra metadata.

Specifically, we could associate any piece of generated code with a Stacktrace that points to the exact line responsible for this generation.
The IDE could then use this StackTrace to jump to the macro code ; how could display the whole stacktrace to help debugging.

Of course, accessing the StackTrace can be slow.
For the sake of efficiency, I see two possible solutions:

  • Gate this behind a flag ; be it an IDE config or an analysis_options.yaml config or something else
  • Alternatively, we could decide not to collect stacktraces initially. And whenever a the IDE requests for a stacktrace at a given offset, we could re-execute macros that were applied on a file, with StackTrace collection enabled.
    Considering a macro should have a deterministic output, this shouldn't cause the IDE to jump to the wrong file/line.
@dart-github-bot
Copy link
Collaborator

Summary: The user proposes adding a mechanism to associate generated code with the stack trace of the macro that generated it. This would allow users to easily navigate from generated code back to the macro code responsible for its creation, aiding in debugging complex code generators.

@dart-github-bot dart-github-bot added area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. triage-automation See https://github.com/dart-lang/ecosystem/tree/main/pkgs/sdk_triage_bot. type-enhancement A request for a change that isn't a bug labels Oct 18, 2024
@lrhn
Copy link
Member

lrhn commented Oct 18, 2024

It can take a lot of time to find exactly which line was responsible for generating a specific code.

How would one define which line was responsible for a specific output?
The one that called the macro server with output?

I can see myself writing a macro that does a whole bunch of computations and then spits out code using a templating mechanism at the end. Telling you that the code was generated by a function called _templateWrite isn't useful.
There may be a stack trace, but there may also not be one that's useful. Just like it's not useful that all the output of a command line program comes from the line print(combinedOutput);.

@pq pq added analyzer-server P2 A bug or feature request we're likely to work on feature-macros Implementation of the macros feature labels Oct 18, 2024
@rrousselGit
Copy link
Author

How would one define which line was responsible for a specific output?
The one that called the macro server with output?

We'd use the stacktrace to the "write(code)" line, whatever api that is.

I can see myself writing a macro that does a whole bunch of computations and then spits out code using a templating mechanism at the end. Telling you that the code was generated by a function called _templateWrite isn't useful.

Indeed.
But one could argue that the problem is your API ; which isn't very debuggable.

If you were to write your macro with:

write(someFunction())

When the stacktrace points to write, you'll know that someFunction was involved.

@lrhn lrhn added pkg-macros The experimental package:_macros library and removed area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. analyzer-server triage-automation See https://github.com/dart-lang/ecosystem/tree/main/pkgs/sdk_triage_bot. labels Oct 18, 2024
@srawlins srawlins added the area-pkg Used for miscellaneous pkg/ packages not associated with specific area- teams. label Oct 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-pkg Used for miscellaneous pkg/ packages not associated with specific area- teams. feature-macros Implementation of the macros feature P2 A bug or feature request we're likely to work on pkg-macros The experimental package:_macros library type-enhancement A request for a change that isn't a bug
Projects
Development

No branches or pull requests

5 participants