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

Improved opt-in logging support #7437

Open
wants to merge 27 commits into
base: main
Choose a base branch
from

Conversation

Daniel1464
Copy link

@Daniel1464 Daniel1464 commented Nov 27, 2024

Allows users to annotate fields and methods with @Logged without putting the @Logged(strategy = Strategy.OPT_IN) moniker on their class to allow opt-in logging on those fields/methods. Solves #6916.

@Daniel1464 Daniel1464 requested a review from a team as a code owner November 27, 2024 16:04
@Daniel1464
Copy link
Author

/format

@SamCarlberg
Copy link
Member

I think you're overcomplicating things. The solution is really just to tweak the criteria when determining if a type is loggable or not. Currently, that criteria is set to the presence of an @Logged annotation, but it should be changed to look for either that or the presence of a @Logged field or method

@SamCarlberg
Copy link
Member

/format

@@ -59,6 +59,45 @@ public void update(DataLogger dataLogger, Example object) {
assertLoggerGenerates(source, expectedGeneratedSource);
}

@Test
void basicOptInLogging() {
Copy link
Member

Choose a reason for hiding this comment

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

I'd call this something like "implicit" logging. The opt-in here is done on the field or method level, so the class itself is implicitly loggable

Comment on lines 69 to 70
@Logged double x;
@Logged double y;
Copy link
Member

Choose a reason for hiding this comment

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

A separate test that checks for a logged method would be useful, too

@Daniel1464
Copy link
Author

I think you're overcomplicating things. The solution is really just to tweak the criteria when determining if a type is loggable or not. Currently, that criteria is set to the presence of an @Logged annotation, but it should be changed to look for either that or the presence of a @Logged field or method

Cool; i didn't know that the current code worked directly with field + method elements

@Daniel1464
Copy link
Author

/format

@Daniel1464
Copy link
Author

/format

@SamCarlberg
Copy link
Member

@Daniel1464 You'll need to merge the main branch and update tests; DataLogger has been renamed to EpilogueBackend

Comment on lines 72 to 73
@Logged public double getValue() { return 2.0; }
@Logged public boolean isActive() { return false; }
Copy link
Member

Choose a reason for hiding this comment

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

These would be better in a separate test, so we can check that just a logged field is enough to make a class logged, and that just a logged method is also enough. Having both in one test means it's ambiguous, and also means that if either field or method detection breaks (but not both), then it wouldn't be caught by the test cases.

@Test
void implicitLoggedFields() {
  String source =
    """
    package edu.wpi.first.epilogue;

    class Example {
      @Logged double x;
    }
    """;

  // ...
}

@Test
void implicitLoggedMethods() {
  String source =
    """
    package edu.wpi.first.epilogue;

    class Example {
      @Logged
      public double x() { return 42; }
    }
    """;

  // ...
}

Additionally, it'd be good to have another test to cover the null case of a class with no @Logged annotation and with no implicitly logged members to make sure we don't generate loggers for things that users didn't opt into

@Daniel1464
Copy link
Author

/format

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