[epilogue] Detailed trigger dependencies #8253

Raptorly1 · 2025-09-25T04:01:43Z

Add @DependsOn annotation to hopefully resolve the following issue: #8233

@DependsOn is on the Epilogue logging framework, allowing fields and methods marked with @Logged to declare dependencies on other data points in the same class.

The changes include annotation processor updates, logger code generation updates, and new tests to verify the behavior.

Let me know what you all think!

This annotation allows users to mark logged fields and methods as dependent on other data points for analysis tools like AdvantageScope. This is particularly useful for complex conditions like triggers where understanding the component values is important for debugging. The annotation is @repeatable to allow multiple dependencies and targets both fields and methods. It includes comprehensive documentation with examples showing usage on trigger conditions. Addresses: wpilibsuite#8233

@dependsOn

Adds @dependsOn to the supported annotation types list in the annotation processor, enabling the processor to discover and handle classes that use dependency metadata annotations. This establishes the foundation for processing @dependsOn annotations during the compilation phase. Addresses: wpilibsuite#8233

@dependsOn

Adds comprehensive support for @dependsOn annotations in the logger generation process: - generateDependencyLogging() processes @dependsOn annotations on logged elements and generates additional logging calls for their dependencies - findDependencyElement() searches the class hierarchy for dependency elements by name, supporting both fields and methods - Dependency logging calls are generated alongside main element logging This enables analysis tools like AdvantageScope to automatically log related values when logging complex conditions, providing better debugging visibility without manual logging setup. The implementation handles: - Single and multiple @dependsOn annotations via @repeatable support - Field and method dependencies with proper name resolution - Class hierarchy traversal to find dependencies in superclasses - Integration with existing element handlers for consistent logging Addresses: wpilibsuite#8233

@dependsOn

Adds comprehensive test coverage for the @dependsOn annotation functionality, verifying that: - The annotation processor correctly recognizes @dependsOn annotations - Multiple dependencies can be declared on a single element - Generated logger code includes logging calls for all declared dependencies - Dependencies are resolved correctly within the class The test uses a realistic scenario with position, target, and tolerance fields that are dependencies of an isAtTarget() method, matching the use case described in the GitHub issue. Addresses: wpilibsuite#8233

SamCarlberg · 2025-09-25T12:56:33Z

epilogue-processor/src/test/java/edu/wpi/first/epilogue/processor/AnnotationProcessorTest.java

+            backend.log("position", object.position);
+            backend.log("target", object.target);
+            backend.log("tolerance", object.tolerance);


These extra logging calls are redundant, they'll just add extra overhead to the logger. I'd want to see these names in metadata for the isAtTarget logging invocation - that'll mean updating EpilogueBackend to accept a metadata argument on all the log methods, and update the NT and File backends to use that metadata

These extra logging calls are redundant, they'll just add extra overhead to the logger. I'd want to see these names in metadata for the isAtTarget logging invocation - that'll mean updating EpilogueBackend to accept a metadata argument on all the log methods, and update the NT and File backends to use that metadata

Sounds good. I made the changes.

SamCarlberg · 2025-09-25T13:02:33Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

+    // For each dependency, find the corresponding element and generate logging
+    for (DependsOn dependency : dependencies) {
+      String dependencyName = dependency.value();
+      Element dependencyElement = findDependencyElement(clazz, dependencyName);


You can just look up elements in the fieldsToLog and methodsToLog lists, no need to walk the class hierarchy again

You can just look up elements in the fieldsToLog and methodsToLog lists, no need to walk the class hierarchy again

Thanks!

Here is how I do it now

// Precompute set of logged names for efficient lookup Set<String> loggedNames = Stream.concat(fieldsToLog.stream(), methodsToLog.stream()) .map(ElementHandler::loggedName) .collect(Collectors.toSet()); // Collect valid dependency names by checking against logged elements List<String> validDependencyNames = new ArrayList<>(); for (DependsOn dependency : dependencies) { String dependencyName = dependency.value(); if (loggedNames.contains(dependencyName)) { validDependencyNames.add(dependencyName); } }

SamCarlberg · 2025-09-25T13:12:54Z

epilogue-processor/src/test/java/edu/wpi/first/epilogue/processor/AnnotationProcessorTest.java

+            backend.log("position", object.position);
+            backend.log("target", object.target);
+            backend.log("tolerance", object.tolerance);
+            backend.log("isAtTarget", object.isAtTarget());


This generated call should be something like backend.log("isAtTarget", object.isAtTarget, new LogMetadata(List.of("position", "target", "tolerance")));. A lambda-based approach to cut down on redundant object allocations would also work; metadata won't change so there's no point to specify it on every call

I don't think a lambda-based approach (assuming you mean passing a lambda to the method to create the LogMetadata instead of constructing a new LogMetadata every time) would help with redundant object allocations, since the lambda object still gets allocated every time. (After all, #8190 explicitly removed lambda usage to avoid allocating the lambda objects) I think the only solutions to avoid redundant object allocations are either a) caching the LogMetadata object or b) checking somehow if this is the first log call to determine if the metadata needs to be provided.

@KangarooKoala Thanks for the elaboration! I followed through with a:

caching the LogMetadata object

// Static field declaration private static final LogMetadata $metadata_..._isAtTarget; // Static initializer static { $metadata_..._isAtTarget = new LogMetadata(List.of("position", "target", "tolerance")); } // Usage (reuses cached object) backend.log("isAtTarget", object.isAtTarget(), $metadata_..._isAtTarget);

I also updated tests in /AnnotationProcessorTest.java to match new static field caching approach instead of inline construction

Introduces LogMetadata to provide context about dependencies between logged data points, enabling better analysis in tools like AdvantageScope.

Adds overloaded log methods that accept LogMetadata parameter for dependency tracking. Default implementations delegate to existing methods for backward compatibility.

@dependsOn

Refactored to generate LogMetadata for @dependsOn annotations, replacing individual dependency logging with consolidated metadata approach. Conditionally imports LogMetadata only when needed.

Modified annotation processor test to expect LogMetadata import and consolidated dependency logging in generated logger classes.

…in LoggerGenerator and update test to use cached LogMetadata

…s for improved dependency tracking

SamCarlberg · 2025-09-26T04:00:43Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

+        .map(name -> "\"" + name + "\"")
+        .collect(java.util.stream.Collectors.joining(", "));
+
+    return "new edu.wpi.first.epilogue.logging.LogMetadata(java.util.List.of(" + dependencyList + "))";


Let's actually store metadata as fields in the generated loggers, eg:

class ExampleLogger extends ClassSpecificLogger<Example> { private final LogMetadata fooMetadata = new LogMetadata(List.of("x", "y", "z")); @Override public void update(EpilogueBackend backend, Example object) { if (Epilogue.shouldLog(Logged.Importance.DEBUG)) { backend.log("x", object.x); backend.log("y", object.y); backend.log("z", object.z); backend.log("foo", object.foo, fooMetadata); } } }

This would require two generation steps: one to create the fields, and another to reference them in the logging calls.

SamCarlberg · 2025-09-26T04:02:05Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

-                        out.println(dependencyInvocation.indent(6).stripTrailing() + ";");
+                      var metadata = generateLogMetadata(loggableElement, clazz);
+                      if (metadata != null) {
+                        var modifiedInvocation = logInvocation.replaceFirst("\\)$", ", " + metadata + ")");


It'd be better to have the element handler generate the metadata arguments instead of manipulating the return values after the fact; it can be tricky to handle all possible cases with string manipulation.

Splitting the metadata to be declared as a field also means the element handler can just emit element.getSimpleName() + "Metadata" without needing to know about anything the metadata depends upon

SamCarlberg · 2025-09-26T04:03:53Z

epilogue-runtime/src/main/java/edu/wpi/first/epilogue/logging/LogMetadata.java

+ * or relationships with other logged values. This is particularly useful for analysis
+ * tools like AdvantageScope to understand complex conditions and triggers.
+ */
+public final class LogMetadata {


This could be a record. Additionally, declaring a default empty metadata object (eg LogMetadata.kEmpty or some such) would be useful for logging that doesn't have metadata

Sounds good

public record LogMetadata(List<String> dependencies) { public static final LogMetadata kEmpty = new LogMetadata(List.of());

SamCarlberg · 2025-09-26T04:19:01Z

epilogue-runtime/src/main/java/edu/wpi/first/epilogue/logging/EpilogueBackend.java

+  default void log(String identifier, int value, LogMetadata metadata) {
+    log(identifier, value);
+  }


These should be flipped: log(identifier, value) should delegate to log(identifier, value, LogMetadata.kEmpty)

You will also need to implement these methods for NTEpilogueBackend and FileBackend and tweak those classes so they'll use the metadata that's passed in. (This code is mostly for example; improvements could certainly be made to reduce code duplication and unnecessary setProperties/setMetadata calls when the log metadata is empty)

// NTEpilogueBackend.java private static <T extends Topic> T topicWithMetadata(T topic, LogMetadata metadata) { var dependenciesJson = metadata.dependencies().stream().map(d -> '"' + d + '"').join(Collectors.joining(", ", "[", "]")); String metadataJson = """ { "dependencies": %s } """.trim().formatted(metadataJson); topic.setProperties(metadataJson); return topic; } @Override public void log(String identifier, int value, LogMetadata metadata) { if (m_publishers.containsKey(identifier)) { ((IntegerPublisher) m_publishers.get(identifier)).set(value); } else { var publisher = topicWithMetadata(m_nt.getIntegerTopic(identifier), dependencies).publish(); m_publishers.put(identifier, publisher); publisher.set(value); } } // ... etc for other logging methods

// FileBackend.java @SuppressWarnings("unchecked") private <E extends DataLogEntry> E getEntry(String identifier, BiFunction<DataLog, String, ? extends E> ctor, LogMetadata metadata) { if (m_entries.get(identifier) != null) { return (E) m_entries.get(identifier); } var entry = ctor.apply(m_dataLog, identifier); var dependenciesJson = metadata.dependencies().stream().map(d -> '"' + d + '"').join(Collectors.joining(", ", "[", "]")); String metadataJson = """ { "dependencies": %s } """.trim().formatted(metadataJson); entry.setMetadata(metadataJson); m_entries.put(identifier, entry); return entry; } @Override public void log(String identifier, int value, LogMetadata metadata) { getEntry(identifier, IntegerLogEntry::new, metadata).append(value); } // ... etc for other logging methods

These should be flipped: log(identifier, value) should delegate to log(identifier, value, LogMetadata.kEmpty)

You will also need to implement these methods for NTEpilogueBackend and FileBackend and tweak those classes so they'll use the metadata that's passed in.

Understood.

I changed all abstract methods to default methods that delegate to metadata versions. Heres an example:
before:

void log(String identifier, int value);

after:

default void log(String identifier, int value) { log(identifier, value, LogMetadata.kEmpty); }

SamCarlberg · 2025-09-26T04:25:25Z

epilogue-processor/src/test/java/edu/wpi/first/epilogue/processor/AnnotationProcessorTest.java

+        private static final LogMetadata $metadata_edu_wpi_first_epilogue_Example_isAtTarget;
+
+        static {
+          $metadata_edu_wpi_first_epilogue_Example_isAtTarget = new edu.wpi.first.epilogue.logging.LogMetadata(java.util.List.of("position", "target", "tolerance"));


Let's have imports for these types. Even though the file is generated, it'd be nice to be more human-friendly

SamCarlberg · 2025-09-26T04:30:00Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

+   */
+  public static String logMetadataFieldName(Element element) {
+    return "$metadata_%s_%s"
+        .formatted(element.getEnclosingElement().toString().replace(".", "_"), element.getSimpleName());


How will this behave if a logged field and a logged method have the same simple name?

@Logged class Example { @Logged int foo = 0; @Logged public int foo() { return 42; } }

It compiles right now, but that's a good question. Should I try making it disambiguous? Maybe we could append suffixes?

KangarooKoala · 2025-09-26T06:49:02Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

+  /**
+   * Finds an element (field or method) in a class by name.
+   *
+   * @param clazz the class to search in
+   * @param name the name of the element to find (method names should include parentheses)
+   * @return the found element, or null if not found
+   */


This doc comment without a method should get cleaned up.

KangarooKoala · 2025-09-26T06:57:35Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

+          out.printf(
+              "  // Cached LogMetadata for element %s with @DependsOn annotations%n",
+              element.getSimpleName());
+          out.printf("  private static final LogMetadata %s;%n", logMetadataFieldName(element));


Why can't we initialize the LogMetadata caches inline with the field declarations? (e.g., private static final LogMetadata $metadata_edu_wpi_first_epilogue_Example_isAtTarget = new LogMetadata(List.of("position", "target", "tolerance"));)
This would mean that we can remove the code in the static {} initializer block, which would greater simplify the logic.

KangarooKoala · 2025-09-26T07:03:34Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

+                      // Generate log invocation for the main element
+                      var metadata = generateLogMetadata(loggableElement, loggableFields, loggableMethods);
+                      if (metadata != null) {
+                        var modifiedInvocation = logInvocation.replaceFirst("\\)$", java.util.regex.Matcher.quoteReplacement(", " + metadata + ")"));


Can we import Matcher here?

KangarooKoala · 2025-09-26T07:07:25Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

+   * @param useStaticField if true, return static field reference; if false, return inline construction
+   * @return LogMetadata construction code or field reference, or null if no valid dependencies
+   */
+  private String generateLogMetadata(Element element, List<VariableElement> fieldsToLog, List<ExecutableElement> methodsToLog, boolean useStaticField) {


Instead of a single method with very different return values based on a boolean flag (which is hard to remember which is which), would it be better to refactor this into a collectLogDependencies() method (returning dependencies from the current version of the code) and a generateLogMetadata() method (using collectLogDependencies() and not using useStaticField)?

…logueBackend and update LoggerGenerator to use instance fields for LoggerGenerator

SamCarlberg · 2025-09-28T21:46:06Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

  public static String logMetadataFieldName(Element element) {
-    return "$metadata_%s_%s"
-        .formatted(element.getEnclosingElement().toString().replace(".", "_"), element.getSimpleName());
+    String suffix = element instanceof javax.lang.model.element.VariableElement ? "_field" : "_method";


Use imports instead of fully qualified names, please

SamCarlberg · 2025-09-28T21:47:24Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

              "  // Cached LogMetadata for element %s with @DependsOn annotations%n",
              element.getSimpleName());
-          out.printf("  private static final LogMetadata %s;%n", logMetadataFieldName(element));
+          out.printf("  private final LogMetadata %s;%n", logMetadataFieldName(element));


These fields could still be static, just do the initialization inline instead of in the constructor.

SamCarlberg · 2025-09-28T21:47:37Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

+                        var modifiedInvocation =
+                            logInvocation.replaceFirst(
+                                "\\)$",
+                                java.util.regex.Matcher.quoteReplacement(", " + metadata + ")"));


FQN should be an import

SamCarlberg · 2025-09-28T21:47:52Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

+      String dependencyList =
+          validDependencyNames.stream()
+              .map(name -> "\"" + name + "\"")
+              .collect(java.util.stream.Collectors.joining(", "));


FQN should be an import

SamCarlberg · 2025-09-28T21:49:23Z

epilogue-runtime/src/main/java/edu/wpi/first/epilogue/logging/FileBackend.java

-  @SuppressWarnings("PMD.UnnecessaryCastRule")
  public void log(String identifier, int[] value) {
    long[] widened = new long[value.length];
-    for (int i = 0; i < value.length; i++) {
-      widened[i] = (long) value[i];
-    }
+    java.util.Arrays.setAll(widened, i -> value[i]);


These changes are unrelated and should be reverted

SamCarlberg · 2025-09-28T21:52:09Z

epilogue-runtime/src/main/java/edu/wpi/first/epilogue/logging/FileBackend.java

+
+    if (!m_entries.containsKey(identifier)) {
+      var entry = ProtobufLogEntry.create(m_dataLog, identifier, proto);
+      if (!metadata.dependencies().isEmpty()) {


Let's have a function on LogMetadata to check if it's empty or not. For now, it'd just look at the dependencies list, but could be changed in the future if more types of metadata are added

SamCarlberg · 2025-09-28T21:52:38Z

epilogue-runtime/src/main/java/edu/wpi/first/epilogue/logging/FileBackend.java

+      if (!metadata.dependencies().isEmpty()) {
+        var dependenciesJson =
+            metadata.dependencies().stream()
+                .map(d -> '"' + d + '"')
+                .collect(Collectors.joining(", ", "[", "]"));
+        String metadataJson =
+            """
+            { "dependencies": %s }
+            """
+                .trim()
+                .formatted(dependenciesJson);


This JSON generation is duplicated in the NT backend, too. Let's move it to a LogMetadata.toJson() method so it's reusable.

SamCarlberg · 2025-09-28T21:54:19Z

epilogue-runtime/src/main/java/edu/wpi/first/epilogue/logging/FileBackend.java

+      if (!metadata.dependencies().isEmpty()) {
+        var dependenciesJson =
+            metadata.dependencies().stream()
+                .map(d -> '"' + d + '"')
+                .collect(Collectors.joining(", ", "[", "]"));
+        String metadataJson =
+            """
+            { "dependencies": %s }
+            """
+                .trim()
+                .formatted(dependenciesJson);
+        entry.setMetadata(metadataJson);


This duplicated JSON code could be DRYed up

SamCarlberg · 2025-09-28T21:54:36Z

epilogue-runtime/src/main/java/edu/wpi/first/epilogue/logging/NTEpilogueBackend.java

+  }
+
+  // Helper method for applying metadata to topics
+  private void applyMetadata(edu.wpi.first.networktables.Topic topic, LogMetadata metadata) {


FQN should be imported

SamCarlberg · 2025-09-28T21:55:56Z

epilogue-runtime/src/main/java/edu/wpi/first/epilogue/logging/FileBackend.java

+    long[] widened = new long[value.length];
+    java.util.Arrays.setAll(widened, i -> value[i]);


Use the original widening code, it's more efficient

…related methods update LogMetadata with isEmpty and toJson methods for better metadata handling

KangarooKoala · 2025-10-02T16:15:21Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

-        out.println("    try {");
-
-        out.println("      var rootLookup = MethodHandles.lookup();");
+        if (requiresVarHandles) {
+          out.println("    try {");
+          out.println("      var rootLookup = MethodHandles.lookup();");
+        }


This if guard is no longer necessary since now requiresVarHandles is the only condition of the outer if-statement.

KangarooKoala · 2025-10-02T16:15:35Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

-            "      throw new RuntimeException("
-                + "\"[EPILOGUE] Could not load private fields for logging!\", e);");
-        out.println("    }");
+        if (requiresVarHandles) {


Same as above.

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

KangarooKoala · 2025-10-02T16:24:29Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

+      if (loggedNames.contains(dependencyName)) {
+        validDependencyNames.add(dependencyName);
+      }


Is silently skipping dependency names that don't match any logged names the best behavior? Should we add tests for this?

KangarooKoala · 2025-10-02T16:26:06Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

+   * @param methodsToLog the list of methods that will be logged
+   * @return List of valid dependency names, or null if no valid dependencies
+   */
+  private List<String> collectLogDependencies(


Maybe I'm missing something, but can't this be static?

KangarooKoala · 2025-10-02T16:27:46Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

+  private String generateLogMetadata(
+      Element element,
+      List<VariableElement> fieldsToLog,
+      List<ExecutableElement> methodsToLog,
+      boolean useStaticField) {


Instead of a boolean parameter, it'd be more readable at the call-site to define methods with two different names. (e.g., generateLogMetadataFieldReference() and generateLogMetadataConstruction(). These are just examples though (and not the best)- If you think a different name would be better, go ahead and try it out!)

… generated LogMetadata accordingly. Also add tests for handling invalid dependency names.

KangarooKoala

Could someone mark old conversations as resolved? (I don't have GitHub permissions to, since I'm neither the author nor someone with write access)

KangarooKoala · 2025-10-10T16:40:09Z

epilogue-processor/src/main/java/edu/wpi/first/epilogue/processor/LoggerGenerator.java

+        out.println();
+      }
+
+      // Static initializer block to load VarHandles only


Did anything change so that this no longer generates reflection fields (which were mentioned in the original version of the comment)?

KangarooKoala · 2025-10-10T16:47:55Z

epilogue-runtime/src/main/java/edu/wpi/first/epilogue/logging/LogMetadata.java

+  public String toJson() {
+    var dependenciesJson =
+        dependencies.stream()
+            .map(d -> '"' + d + '"')


Is it necessary to add logic to address dependencies containing double quotes? It should never happen, so maybe not, but it's still worth considering.

Raptorly1 added 4 commits September 23, 2025 20:52

Raptorly1 requested a review from a team as a code owner September 25, 2025 04:01

github-actions bot added the component: epilogue Annotation-based logging library label Sep 25, 2025

SamCarlberg requested changes Sep 25, 2025

View reviewed changes

Raptorly1 added 6 commits September 25, 2025 16:14

Add LogMetadata class for dependency tracking

2b13f61

Introduces LogMetadata to provide context about dependencies between logged data points, enabling better analysis in tools like AdvantageScope.

Extend EpilogueBackend with metadata-aware log methods

e4ae20d

Adds overloaded log methods that accept LogMetadata parameter for dependency tracking. Default implementations delegate to existing methods for backward compatibility.

Implement dependency metadata generation in LoggerGenerator

815480f

Refactored to generate LogMetadata for @dependsOn annotations, replacing individual dependency logging with consolidated metadata approach. Conditionally imports LogMetadata only when needed.

Update test expectations for dependency metadata feature

98f0f6f

Modified annotation processor test to expect LogMetadata import and consolidated dependency logging in generated logger classes.

Generate LogMetadata fields for elements with @dependsOn annotations …

eb28d17

…in LoggerGenerator and update test to use cached LogMetadata

Refactor generateLogMetadata method to accept fields and methods list…

39e05ea

…s for improved dependency tracking

SamCarlberg reviewed Sep 26, 2025

View reviewed changes

KangarooKoala reviewed Sep 26, 2025

View reviewed changes

calcmogul changed the title ~~Feature/detailed trigger dependencies~~ [epilogue] Detailed trigger dependencies Sep 27, 2025

Raptorly1 added 2 commits September 28, 2025 12:27

Implement metadata-aware logging methods in EpilogueBackend and NTEpi…

37a2e52

…logueBackend and update LoggerGenerator to use instance fields for LoggerGenerator

Add List import and update LogMetadata

3ad142f

SamCarlberg reviewed Sep 28, 2025

View reviewed changes

Raptorly1 added 2 commits October 1, 2025 20:55

Refactor LoggerGenerator to use static LogMetadata fields and update …

539a41d

…related methods update LogMetadata with isEmpty and toJson methods for better metadata handling

change FQN to import

79b132c

KangarooKoala reviewed Oct 2, 2025

View reviewed changes

Raptorly1 force-pushed the feature/detailed-trigger-dependencies branch 3 times, most recently from ec7a461 to 79b132c Compare October 9, 2025 17:39

Update LoggerGenerator to validate @dependsOn dependencies and update…

bcc1eeb

… generated LogMetadata accordingly. Also add tests for handling invalid dependency names.

KangarooKoala reviewed Oct 10, 2025

View reviewed changes

		long[] widened = new long[value.length];
		java.util.Arrays.setAll(widened, i -> value[i]);

[epilogue] Detailed trigger dependencies #8253

Are you sure you want to change the base?

[epilogue] Detailed trigger dependencies #8253

Conversation

Raptorly1 commented Sep 25, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SamCarlberg Sep 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KangarooKoala left a comment

SamCarlberg Sep 26, 2025 •

edited

Loading