Skip to content
This repository has been archived by the owner on Feb 4, 2025. It is now read-only.

Evaluate changes to generators for macros / augmentation libraries #14

Closed
davidmorgan opened this issue Mar 12, 2024 · 5 comments
Closed
Assignees
Labels
P2 A bug or feature request we're likely to work on type-question A question about expected behavior or functionality

Comments

@davidmorgan
Copy link
Contributor

Macros will introduce augmentation libraries; what changes are needed to widely-used generators so that they continue to work?

The analyzer exposes new API that will need to be used in some cases, see e.g. mentions of "augmentation" in package:analyzer/dart/element/element.dart.

@davidmorgan davidmorgan self-assigned this Mar 12, 2024
@davidmorgan
Copy link
Contributor Author

Simplest things I could think of with mockito, mocking a macro-added field and a macro-added type, both seem to work without changes

dart-lang/mockito@master...davidmorgan:mockito:built-with-macros

although I did hit an issue with "asset" paths that I'll report over in the "build" repo, and an issue with augmenting a class that generics that I guess I'll add a language test for.

@mit-mit mit-mit added the type-question A question about expected behavior or functionality label Mar 18, 2024
@eernstg
Copy link

eernstg commented Mar 18, 2024

Perhaps this is not a question about language specification documents, but rather about the behavior of code generators? In that case we might consider area-tools rather than area-specification.

@davidmorgan
Copy link
Contributor Author

Yes, it's not spec related. It's about the effect of macro implementation details on existing code generators ... actually that specifically means the analyzer API, I'll tag it with that. Thanks.

@pq pq added the P2 A bug or feature request we're likely to work on label Mar 18, 2024
@davidmorgan
Copy link
Contributor Author

A related issue to this one is build performance of generators + macros.

There are cases where external use of generators is pushing the limits of performance, one is mentioned here dart-lang/language#314 (comment) and another is here google/built_value.dart#1288

It would be useful to know what happens to these with macros thrown into the mix: is there a viable path to macros that goes via some mix of macros and generators, or is that going to be too slow, and they'll have to switch to macros in one shot?

@davidmorgan davidmorgan transferred this issue from dart-lang/sdk Jun 27, 2024
@davidmorgan
Copy link
Contributor Author

I noticed in the analyzer's element.dart that there are deprecations pointing to "augmented" getters that give the merged information with augmentations, e.g.:

  @Deprecated('Use `element.augmented.lookUpMethod`.')
  MethodElement? lookUpMethod(String methodName, LibraryElement library);

So this is another type of updates generators will need if they should interact with augmentations as if they are pre-augmentation code.

@davidmorgan davidmorgan closed this as not planned Won't fix, can't repro, duplicate, stale Feb 3, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P2 A bug or feature request we're likely to work on type-question A question about expected behavior or functionality
Development

No branches or pull requests

4 participants