Rework Analyzer/Source Generator support #452
Conversation
## What? Reworks the analyzer/source generator support so that it more robust and so that end users can use and author source generators
|
@tomdegoede Any chance you could look over this? I don't use analyzers/source generators daily so I don't have much experience with them. |
There was a problem hiding this comment.
This looks good! We (thankfully) never ran into the language specific analyzers. Personally I would prefer not to mention vb, cs and fs in many places. Would it be possible to convert analyzers and transitive_analyzers on the provider to a dict() of analyzer depsets keyed by ("", "vb", "cs", "fs")? You can then propagate the analyzers from collect_compile_info as: depset(transitive = [analyzers.get("", depset()), analyzers.get(language, depset())]).
I don't like the lang prefixes either. Will see if I can use your suggestion to get rid of most of them. |
|
Going to keep it like it is for now, I've got some refactoring ideas to get rid of some of the duplication between languages but I don't have time to do it now. I don't consider the providers public interfaces at the moment so I'm not too worried about breaking changes there. |
|
No problem. We are currently adding support for VB and WPF to our setup. I have open-sourced a minimal setup here: https://github.com/AFASResearch/bazel-template. In case you are interested in how we minimalize code duplication, everything still lives in binary.bzl and assembly.bzl. |
What?
Reworks the analyzer/source generator support so that it more robust and so that end users can use and author source generators