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 follow-up: Support emitting diagnostics in the generated code #60062

Open
rrousselGit opened this issue Feb 6, 2025 · 4 comments
Open
Labels
area-tools A meta category for issues that should be addressed by tooling (prefer more concrete areas). type-enhancement A request for a change that isn't a bug

Comments

@rrousselGit
Copy link

One very useful feature Macros proposed was the ability to emit custom errors/warnings.
This was helpful because code-generators often have some form of error cases.

Since macros are cancelled, could we maybe have some dumbed down version of this?

Proposal: A custom comment similar to // ignore for emitting diagnostics

One way generators could emit diagnostics could be through comments.
For example, we could imagine a generator output:

// @diagnostic kind=error line=10 colum=5 message="You must provide a constuctor"

This would output an error in the associated file, with the given parameters.

Bonus: Have build or source_gen automatically emit such comment when an exception is thrown by generators

Currently, generators rely on throwing InvalidSourceException to emit similar error reports.
The generation tooling could catch those and output a corresponding // @diagnostic,

@dart-github-bot
Copy link
Collaborator

Summary: User requests a mechanism to emit custom diagnostics from code generators, suggesting a // @diagnostic comment format as a replacement for cancelled macro functionality.

@dart-github-bot dart-github-bot added area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). 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 Feb 6, 2025
@bwilkerson
Copy link
Member

I would love to have a way for the analyzer and the compilers to emit diagnostics that are generated by a code generator. My expectation is that generator authors would use this feature to provide a better UX for their users.

I would prefer to have support for this that doesn't require writing the diagnostics into the generated code. I think the UX would be much better if they are communicated to the tools in a different way. But if we can't find a better way to get the diagnostic information then I think we should explore using generated output, whether a comment or an annotation, as a means of getting this information to the tools.

(A note to possible designers: there's more information about a diagnostic that I'd want to have communicated than what's proposed in the above example.)

@davidmorgan For visibility.

@davidmorgan
Copy link
Contributor

build_runner issue: dart-lang/build#3806

Yes, for sure we want a way for generators to report diagnostics--and fixes.

More generally what we want is an information channel generator -> analysis server.

.dart_tool/build_result.json? :)

@bwilkerson
Copy link
Member

The specifics of the communication channel depends on the architecture of the system. Once we know how and when we're going to generate code I suspect that the choice of a communication channel will be fairly obvious.

@lrhn lrhn added area-tools A meta category for issues that should be addressed by tooling (prefer more concrete areas). and removed area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). triage-automation See https://github.com/dart-lang/ecosystem/tree/main/pkgs/sdk_triage_bot. labels Feb 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-tools A meta category for issues that should be addressed by tooling (prefer more concrete areas). type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

5 participants