Skip to content

Comments

In BasicAnnotationProcessor, correctly defer non-type elements rejected by processing steps.#1702

Closed
copybara-service[bot] wants to merge 0 commit intomainfrom
test_main_602032802
Closed

In BasicAnnotationProcessor, correctly defer non-type elements rejected by processing steps.#1702
copybara-service[bot] wants to merge 0 commit intomainfrom
test_main_602032802

Conversation

@copybara-service
Copy link
Contributor

@copybara-service copybara-service bot commented Jan 27, 2024

In BasicAnnotationProcessor, correctly defer non-type elements rejected by processing steps.

See #1348 for details. If a processor is triggered by a method annotation, for example, and the processor rejects the method until the next round, then we should defer processing of just that method, not the entire class containing it.

Closes #1348.

RELNOTES=BasicAnnotationProcessor has improved handling of deferring processing of methods and other non-type elements. Thanks to @AriaAdibi for this contribution!

@copybara-service copybara-service bot force-pushed the test_main_602032802 branch 2 times, most recently from 3610d40 to 4eef5cd Compare January 30, 2024 19:31
@eamonnmcmanus
Copy link
Member

@AriaAdibi our internal review led to extensive but superficial changes. We'd certainly be interested in your opinion, either before or after this change is merged.

Copy link
Contributor

@AriaAdibi AriaAdibi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All good. Thank you for the opportunity. I just added some minor subjective opinion regarding the naming.

* enclosing-type in its entirety should be well-formed. Since modules
* don't get annotated (and are not supported here) they can be ignored.
*/
private final Set<PackageOrTypeElementFactory> deferredElementFactories = new LinkedHashSet<>();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

enclosing-type: As pointed out here, if the element is a TypeElement enclosing-type might refer to a step further such element; however, in this case, we mean the element itself. Personally, I have no problem with enclosing-type being inclusive; I just wanted to point it out.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another subjective matter regarding the naming: The first time I read the code, I was somewhat confused about why the code has both deferredElement** and elementsDeferredBySteps. That is why I personally prefer renaming the first to signify those are the elements defered due to being ill-formed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, we're still debating the names. Naming Is Hard.

Copy link
Contributor

@AriaAdibi AriaAdibi Jan 31, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another naming caught my eye now, and I just wanted to share my opinion again. :) I still prefer my Blueprint name idea, since to me, factory usually means that something will be created. However, that is not the case here. The element is looked for (not created) that has certain characteristics.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naming Is Still Hard. :-) I think a Blueprint also implies creation, doesn't it? If it's something you use to find an existing thing, that's more like a Key. But also, it may actually be that a new object is created when you ask for the same method in a later round. And, in practice it's not unusual for a factory to be able to return an existing cached object rather than a new one.

private void reportMissingElements(Set<ElementFactory> missingElementFactories) {
for (ElementFactory missingElementFactory : missingElementFactories) {
Element missingElement = missingElementFactory.getElement(elementUtils);
if (missingElement != null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since empty is expected, I personally prefer the use of Optional instead.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would be inclined to agree if we could use Optional.ifPresentOrElse here. Then we wouldn't have the ugly .ifPresent...get pattern. Unfortunately we're still building on Java 8 and ifPresentOrElse was only added in Java 9.

@copybara-service copybara-service bot changed the title In BasicAnnotationProcessor, correctly defer non-type elements referencing missing types. In BasicAnnotationProcessor, correctly defer non-type elements rejected by processing steps. Jan 31, 2024
@copybara-service copybara-service bot force-pushed the test_main_602032802 branch 2 times, most recently from b64af3f to fd767a5 Compare January 31, 2024 20:58
@copybara-service copybara-service bot closed this Jan 31, 2024
@copybara-service copybara-service bot deleted the test_main_602032802 branch January 31, 2024 21:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants