Diagnostics for DynComp#739
Conversation
📝 WalkthroughWalkthroughThis pull request adds Javadoc to DaikonVariableInfo.toString() and a TODO in check_for_dup_names(), introduces two private DVSet constructors and a package-private dvSetsToString(List, int) helper in DCRuntime, adds diagnostic/IO imports, and leaves an inert duplicate-name diagnostic block in merge_dv_comparability. Build tweaks: tests/Makefile.common replaces hardcoded make invocations with the MAKE variable, and doc/Makefile adds OS-aware conditional use of a CRONIC wrapper for makeinfo. No runtime behavioral changes were introduced. Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 1✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
java/daikon/dcomp/DCRuntime.java (1)
239-246: Collection constructor only used in disabled code.The
DVSet(Collection<DaikonVariableInfo> variables)constructor is currently only invoked within theif (false)block at line 2473, meaning it's not actively used. While this appears to be scaffolding for future diagnostics, consider whether this constructor should remain until it's actually needed.
🤖 Fix all issues with AI agents
In @java/daikon/dcomp/DCRuntime.java:
- Around line 2447-2452: The two TODOs in DCRuntime.java indicate a design
problem: the method that currently accepts a RootInfo should be refactored to
take only the relevant DaikonVariableInfo (or a well-named wrapper like
ProgramPointVars) and to prevent merges across different program points; change
the method signature(s) that reference RootInfo to instead accept a
Collection<DaikonVariableInfo> or a ProgramPointVars object (update all
callers), add an explicit program-point identity parameter (e.g., String
programPointId) and assert/throw if merging is attempted for mismatched ids,
remove the TODOs and add Javadoc on the new method(s) explaining why RootInfo
was dropped and the invariants about program-point-only merges, and add/adjust
unit tests to cover the new signature and the mismatch error path.
- Around line 2462-2476: The disabled duplicate-name check (the if(false) block
around the check using dest_map, dest_var_name, dest_var, DaikonVariableInfo,
varlist(dest), and DVSet) is dead code — either remove the block and the
now-unused DVSet(Collection<DaikonVariableInfo>) constructor, or make the check
controllable and correct: replace if(false) with a runtime/debug flag (e.g.,
DEBUG_CHECK_DUPLICATE_DEST_VAR) and re-enable the logic, or if duplicates are
legitimate change the throw to a diagnostic warning/log (including the offending
names via dest_var_name and DVSet(varlist(dest))). Ensure any retained check
uses varlist(dest) correctly and that merge_dv_comparability remains consistent
with the chosen behavior.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
java/daikon/dcomp/DCRuntime.java
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (11)
- GitHub Check: codespecs.daikon (typecheck_latest_part3_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_latest_part2_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_latest_part1_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part1_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part2_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part3_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (quick_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (misc_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (nontxt_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (kvasir_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (nonquick_ubuntu_jdk25)
🔇 Additional comments (3)
java/daikon/dcomp/DCRuntime.java (3)
22-23: LGTM!The new imports are appropriately used by the debugging helper methods added in this PR.
Also applies to: 25-25, 31-31, 36-36, 46-46
264-270: LGTM!The
toStringWithIdentityHashCode()method provides useful debugging output that includes identity hash codes, which is valuable for diagnosing comparability issues where object identity matters.
2309-2329: The suggestion is incompatible with the project's Java 8 support.The Makefile shows this project targets Java 8 as its minimum version (
-source 8 -target 8in the fallback case). ThePrintStream(OutputStream, boolean, Charset)constructor you suggested was introduced in Java 10, making the proposed change a breaking compatibility issue.The current implementation using
StandardCharsets.UTF_8.name()with thePrintStream(OutputStream, boolean, String)constructor is the correct approach for Java 8 compatibility. TheUnsupportedEncodingExceptioncatch is also necessary since it's a checked exception declared by this constructor variant.Likely an incorrect or invalid review comment.
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In @java/daikon/dcomp/DCRuntime.java:
- Around line 2235-2247: The no-arg DVSet() constructor appears unused; remove
the private no-arg constructor DVSet() to reduce dead code, leaving only the
Collection<DaikonVariableInfo> constructor DVSet(Collection<DaikonVariableInfo>
variables), and run compile/tests to ensure nothing depends on it;
alternatively, if you intend to preserve an empty-construction API, keep the
constructor but add a clear JavaDoc comment explaining its intended future use
and why it must remain (and add a unit test or a suppression comment to avoid
IDE warnings).
- Around line 2317-2335: The dvSetsToString method can drop the String-based
UTF-8 handling and the impossible UnsupportedEncodingException: replace the
String utf8 and the PrintStream/ByteArrayOutputStream calls that use names with
the Charset API by using StandardCharsets.UTF_8 (e.g., new PrintStream(baos,
true, StandardCharsets.UTF_8) and baos.toString(StandardCharsets.UTF_8)); remove
the try/catch for UnsupportedEncodingException and let the try-with-resources
just construct the PrintStream and return the baos.toString(Charset), keeping
references to dvSetsToString, DVSet, baos and the PrintStream usage to locate
changes.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
java/daikon/dcomp/DCRuntime.java
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (11)
- GitHub Check: codespecs.daikon (typecheck_latest_part1_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_latest_part2_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_latest_part3_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (misc_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part2_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part1_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (kvasir_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (nonquick_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part3_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (nontxt_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (quick_ubuntu_jdk25)
🔇 Additional comments (2)
java/daikon/dcomp/DCRuntime.java (2)
22-23: LGTM! Imports support new diagnostic methods.The new imports are appropriate for the diagnostic functionality being added (ByteArrayOutputStream/PrintStream for string building, StringJoiner for formatting, and StringsPlume for indentation utilities).
Also applies to: 25-25, 31-31, 36-36, 46-46, 56-56
2264-2278: LGTM! Well-implemented debugging utility.The
toStringWithIdentityHashCode()method provides useful diagnostic output by including identity hash codes alongside variable information. The use ofSystem.lineSeparator()ensures cross-platform compatibility.
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
java/daikon/dcomp/DCRuntime.java (1)
2523-2567: Clarify the intended use of the logging variants.The TODO at lines 2523-2524 questions whether the "noisy"
add_variableshould ever be used. This suggests uncertainty about the API design. Consider:
- If the noisy version is never needed: Remove it and make
add_variablealways quiet, or rename the quiet version to be the default- If the noisy version is useful for debugging: Document when to use each variant and remove the TODO
- If unsure: Audit call sites to determine if any benefit from the verbose logging
Currently, only one call site uses the noisy version explicitly, and the main diagnostic routine (
get_comparable) switched to the quiet variant at line 2302.Suggestion: If no active debugging scenarios require the verbose per-variable logging, simplify the API by removing the public
add_variablemethod and renamingadd_variable_quietlytoadd_variable.
🤖 Fix all issues with AI agents
In @java/daikon/dcomp/DCRuntime.java:
- Around line 2264-2278: The multi-line output from
toStringWithIdentityHashCode() is visually unbalanced because the opening token
uses "DVSet(" while the closing uses " )"; update the opening to include two
leading spaces so it matches the indentation used for each element and the
closing (i.e., change the string passed to result.add for the opening from
"DVSet(" to include two spaces before it) in the toStringWithIdentityHashCode
method to produce consistent indentation.
- Around line 2461-2491: merge_dv_comparability currently disables the
duplicate-name check (if (false)) causing silent overwrites in dest_map when
varlist(dest) contains repeated names; fix by restoring an active duplicate
detection in merge_dv_comparability: iterate varlist(dest), and if dest_map
already contains dest_var.getName() either (a) treat this as a real error and
throw a descriptive Error (include old_dest_var.toStringWithIdentityHashCode()
and dest_var.toStringWithIdentityHashCode()) so the root cause in varlist(dest)
can be diagnosed, or (b) if duplicates are expected, change the map key to a
unique identifier (e.g., name + program point or a variable identity/hash) and
add a concise TODO explaining why duplicates are allowed and conditions for
re-enabling strict checks; also address the related design TODOs by adding a
short comment in merge_dv_comparability noting whether RootInfo should be
narrowed to only relevant DaikonVariableInfo entries and that merges must never
span different program points (and, if feasible, add an assertion to prevent
cross-program-point merges).
In @java/daikon/FileIO.java:
- Around line 1390-1397: Update the catch block comment to clearly state that
total_lines remains 0 and that this disables progress percentage display;
specifically, in the count_lines branch around
FilesPlume.countLines(raw_filename) (guarded by count_lines) replace the vague
comment in the catch for Throwable t with a clearer one such as: leave
total_lines at 0 (already initialized), which disables progress percentage
display — keep behavior unchanged (Daikon.progress and total_lines logic remain
as-is).
- Around line 1048-1058: The warning block incorrectly calls System.out.println
with a format string and argument; change the call that prints "WARNING: Error
while processing trace file %s; remaining records ignored.%n" so it uses
formatted output — for example replace System.out.println(...) with
System.out.printf(...) or System.out.println(String.format(...)) in the branch
guarded by dkconfig_continue_after_file_exception (the block that also prints
"Ignored backtrace:" and calls e.printStackTrace(System.out)); leave the rest of
the logic (printing backtrace and throwing Error) unchanged.
In @tests/Makefile.common:
- Around line 506-516: The error handling uses the wrong variable name and path:
replace the uppercase undefined ${COMPARABILITY_FILE} with the actual lowercase
comparability_file and make both the existence check and the error message use
the full path $(CWD)/${comparability_file}; specifically update the test that
currently checks "$comparability_file" to check "$(CWD)/${comparability_file}"
and update the echo to reference $(CWD)/${comparability_file} so the reported
filename matches what was created by the CHICORY invocation.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (5)
java/daikon/FileIO.javajava/daikon/VarInfo.javajava/daikon/chicory/DaikonVariableInfo.javajava/daikon/dcomp/DCRuntime.javatests/Makefile.common
💤 Files with no reviewable changes (1)
- java/daikon/VarInfo.java
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (11)
- GitHub Check: codespecs.daikon (typecheck_latest_part3_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_latest_part1_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_latest_part2_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (kvasir_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part1_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part3_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (misc_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part2_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (nontxt_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (nonquick_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (quick_ubuntu_jdk25)
🔇 Additional comments (7)
java/daikon/chicory/DaikonVariableInfo.java (3)
198-217: LGTM! Clean separation of concerns for string representations.The refactoring separates the simple string representation (
toString()) from the diagnostic version (toStringWithIdentityHashCode()). This provides better control over when identity information is included.
1398-1412: Good catch documenting the potential design issue.The TODO comment correctly identifies a potential problem: the code uses the first occurrence of a variable name and ignores duplicates, but the first occurrence might be nested (e.g.,
obj.field.x) rather than canonical (e.g.,xat the top level). This could lead to incorrect variable selection in the presence of shadowing or nested scopes.
235-243: The concern about compilation is unfounded. In Java, the+operator works withCharSequencethrough implicittoString()conversion, so line 240'sCharSequence childOffset = offset + "--";compiles successfully without errors.While the code is valid, it could be more explicit: using
String childOffset = offset.toString() + "--";would make the type conversion clearer and better reflect the actual behavior, since the+operator implicitly convertsCharSequencetoStringanyway.java/daikon/FileIO.java (1)
1371-1371: LGTM! Helpful clarification.The comment accurately explains that line counting is only for user-facing progress messages, which justifies why it can be skipped in various scenarios.
java/daikon/dcomp/DCRuntime.java (3)
2073-2073: LGTM: Typo correction.The typo
skinyOutputhas been corrected toskinnyOutputthroughout the file.Also applies to: 2088-2088, 2155-2155, 2170-2170, 2194-2194, 2202-2202
2319-2343: LGTM: Java version compatibility handled correctly.The
dvSetsToStringmethod correctly handles Java 8 compatibility by usingStandardCharsets.UTF_8.name()instead of passing the charset directly. The comment at lines 2327-2332 clearly documents the Java 11+ simplification.
2302-2302: Verify that suppressing logging in diagnostic routine is intentional.The change from
add_variable(sets, dv)toadd_variable_quietly(sets, dv)suppressesdebug_merge_complogging when building comparability sets for diagnostics. While this reduces noise, ensure that:
- Users who enable
debug_merge_complogging still get sufficient information for debugging- The diagnostic output from
get_comparableitself provides enough context without the per-variable loggingIf the removed logging was valuable for debugging, consider adding higher-level logging at the
get_comparablelevel to summarize the sets being built.
markro49
left a comment
markro49
left a comment
There was a problem hiding this comment.
Don't know anything about DVSets but didn't see anything to give me pause.
markro49
left a comment
markro49
left a comment
There was a problem hiding this comment.
ci fail with 'skinyOutput' needing javadoc
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
java/daikon/dcomp/DCRuntime.java (1)
2468-2530: Address architectural TODOs in merge_dv_comparability.The method contains two concerning TODO comments:
Lines 2470-2473: Questions why the method takes a
RootInfowhen it contains "many more variables than we are interested in." This suggests potential inefficiency or design issues.Line 2475: States "We should never merge across different program points" - this is a strong assertion that requires verification.
These comments suggest uncertainty about the correctness of the merging logic. Please either:
- Clarify why the current design is correct and update/remove the TODOs
- Refactor to address the concerns raised
- Add assertions to prevent incorrect usage if "never merging across program points" is a requirement
Do you want me to analyze the call sites of
merge_dv_comparabilityto verify program point boundaries are respected?
🤖 Fix all issues with AI agents
In @java/daikon/dcomp/DCRuntime.java:
- Around line 2335-2352: The dvSetsToString method can be simplified for Java
11+: replace the current ByteArrayOutputStream + PrintStream construction that
passes the charset name string (utf8) and the surrounding try/catch for
UnsupportedEncodingException with the Java 11 pattern that creates PrintStream
using StandardCharsets.UTF_8 directly (e.g., new PrintStream(baos, true,
StandardCharsets.UTF_8)) and return baos.toString(StandardCharsets.UTF_8);
remove the now-unreachable catch block and the utf8 string variable; keep the
loop writing dvset.toStringWithIdentityHashCode() unchanged.
- Around line 2485-2500: The duplicate-name check in merge_dv_comparability (the
disabled if (false) block) is suppressing real validation: re-enable it and fix
handling of duplicates by first diagnosing whether duplicates are identical
variables or true conflicts; inside merge_dv_comparability, replace the
unconditional Error throw with logic that compares existing
dest_map.get(dest_var_name) (old_dest_var) and the new dest_var by identity (==)
or by a unique identity method (toStringWithIdentityHashCode) and if they are
the same variable simply skip re-putting, otherwise handle a true conflict by
either merging the variable info (e.g., combine comparability info) or logging a
clear error and throwing with the full diagnostic message; ensure you still call
dest_map.put(dest_var_name, dest_var) only when appropriate and preserve the
diagnostic construction using new
DVSet(varlist(dest)).toStringWithIdentityHashCode() for logs.
In @java/daikon/FileIO.java:
- Line 1057: The thrown Error for trace file failures in FileIO (the throw new
Error("Error while processing trace file " + filename);) discards the original
exception; update the throw to include the caught exception as the cause (e.g.,
throw new Error("Error while processing trace file " + filename, e);) so the
original stack trace and exception type are preserved; if necessary, ensure the
caught exception variable (e) is in scope or rethrow a suitable
RuntimeException/IOException that accepts a cause while keeping the filename
message.
- Around line 1392-1396: The current catch block around
FilesPlume.countLines(raw_filename) is catching Throwable; narrow this to catch
IOException (or at least Exception) instead to avoid swallowing VM
errors—replace "catch (Throwable t)" with "catch (IOException e)" (or "catch
(Exception e)" if IOException isn't available) and adjust imports if needed,
keeping the body unchanged so total_lines remains 0 on failure.
In @tests/Makefile.common:
- Around line 512-515: The shell variable reference in the conditional uses
$comparability_file without braces; update the if block to use the braced form
${comparability_file} (matching the usage on line 510) to ensure consistency and
avoid word-splitting issues—replace `$comparability_file` with
`${comparability_file}` in that conditional and any nearby occurrences in the
same Makefile snippet.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
java/daikon/FileIO.javajava/daikon/dcomp/DCRuntime.javatests/Makefile.common
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (11)
- GitHub Check: codespecs.daikon (typecheck_latest_part3_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part3_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_latest_part2_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_latest_part1_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part1_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part2_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (nontxt_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (kvasir_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (nonquick_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (quick_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (misc_ubuntu_jdk25)
🔇 Additional comments (9)
java/daikon/FileIO.java (2)
1050-1053: LGTM: Improved error messages with filename context.The enhanced warning messages now include the filename, making it easier to identify which trace file caused the issue. The formatting is clear and consistent.
Also applies to: 1582-1585
1371-1371: LGTM: Helpful clarifying comment.The comment clearly explains that line counting is purely for progress display, which helps justify why failures in the subsequent try-catch block can be safely ignored.
tests/Makefile.common (2)
506-507: LGTM: Good refactoring to extract the comparability file path.Extracting the file path into a named variable improves clarity and maintainability.
510-511: LGTM: Proper variable reference.The use of
${comparability_file}with braces is correct and consistent with shell best practices.java/daikon/dcomp/DCRuntime.java (5)
21-47: LGTM: Import additions support new functionality.All new imports are properly utilized by the diagnostic enhancements (dvSetsToString, DVSet.toStringWithIdentityHashCode, etc.).
2073-2210: LGTM: Typo correction.The renaming from
skinyOutputtoskinnyOutputcorrectly fixes the spelling throughout the codebase.
2244-2287: LGTM: Well-designed diagnostic support.The new constructors and
toStringWithIdentityHashCode()method provide enhanced debugging capabilities. The private visibility of constructors appropriately limits their scope.
2538-2576: These methods are package-private, not public APIs.The methods
add_variable()andadd_variable_quietly()use default visibility (no access modifier), making them package-private, not public. The concerns about public API design and external usage do not apply.However, the existing TODO comment (lines 2532-2533) already questions whether the "noisy" version is useful, suggesting the author's own uncertainty about this method's purpose. If the noisy version remains unnecessary, consider removing it and consolidating the two methods into a single
add_variable_quietly()variant used internally.Likely an incorrect or invalid review comment.
2210-2238: Verify toString() format parsing is still correct.Line 2215 contains a TODO comment: "The
toString()output format has changed; this code might be incorrect now." This raises concerns about the correctness of the parsing logic at lines 2216-2218, which splits the string on ":" to extract variable type and name.Since this affects diagnostic output used in comparability files, incorrect parsing could lead to misleading debugging information.
Please verify that the toString() format hasn't changed, or update the parsing logic if it has. You can test this by:
#!/bin/bash # Check if any tests fail due to incorrect skinnyOutput parsing cd tests make txt-cset && diff *.txt-cset.goal *.txt-cset
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
java/daikon/dcomp/DCRuntime.java (1)
2531-2575: Consider API design: Is the "noisy" version necessary?The new API provides two public entry points:
add_variable(...)- logs diagnostic informationadd_variable_quietly(...)- suppresses loggingHowever, the TODO comment at lines 2531-2532 questions whether the "noisy" version is actually useful or should ever be used.
Questions:
- Are there legitimate use cases for
add_variable()with logging enabled?- If logging is primarily for debugging, should both methods be package-private rather than public?
- Should one of these methods be removed to simplify the API?
The implementation itself is sound, but the API surface may benefit from clarification of intended usage.
Based on the implementation, the methods correctly handle recursive traversal and conditional logging. The delegation pattern is clean.
🤖 Fix all issues with AI agents
In @java/daikon/dcomp/DCRuntime.java:
- Around line 2469-2500: The loop that builds dest_map from varlist(dest)
silently overwrites duplicates because the duplicate-name check was disabled;
re-enable and handle duplicates in the loop over varlist(dest) (using dest_map,
DaikonVariableInfo, dest_var.getName(), and DVSet(varlist(dest)) to identify
collisions). Either (A) treat duplicates as a bug: restore the check and throw
an Error with a diagnostic message that includes
old_dest_var.toStringWithIdentityHashCode(),
dest_var.toStringWithIdentityHashCode(), and the DVSet identities, or (B) if
duplicates are expected, add explicit, documented deduplication logic (choose
and document whether to keep first or last occurrence) and remove the TODO by
explaining why duplicates are acceptable; implement the selected behavior
consistently and add a clear comment describing the invariant so future merges
won’t silently lose variables.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
java/daikon/dcomp/DCRuntime.javatests/Makefile.common
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-10-15T17:49:49.294Z
Learnt from: markro49
Repo: codespecs/daikon PR: 685
File: java/daikon/dcomp/DCInstrument.java:0-0
Timestamp: 2025-10-15T17:49:49.294Z
Learning: The PrintStream(File, Charset) constructor was introduced in Java 10. For Java 8 compatibility, use PrintStream(File, String csn) with the string literal "UTF-8" instead of StandardCharsets.UTF_8.
Applied to files:
java/daikon/dcomp/DCRuntime.java
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (11)
- GitHub Check: codespecs.daikon (typecheck_latest_part1_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_latest_part3_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_latest_part2_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part2_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part1_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part3_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (kvasir_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (misc_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (nonquick_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (quick_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (nontxt_ubuntu_jdk25)
🔇 Additional comments (8)
tests/Makefile.common (2)
501-502: LGTM! Cosmetic line wrap.The dependency line has been reformatted for readability with no functional change.
506-509: Clarify validation timing: pre-condition vs post-run check.The validation checks if
$(PROJECT_FILE).decls-DynCompexists and is non-empty before the Chicory command executes (lines 510-514). However, the AI summary describes this as "post-run validation after Chicory execution."Currently, this functions as a pre-condition check ensuring the comparability file exists before Chicory attempts to use it via the
--comparability-fileflag (line 513). This makes sense if the file is expected to be generated by a prior DynComp step.Questions:
- Is this intended as a pre-condition check (current behavior), or should it validate the file after Chicory completes?
- If it should be post-run validation, the check needs to move after line 515.
java/daikon/dcomp/DCRuntime.java (6)
21-21: LGTM! New imports support diagnostic enhancements.The added imports support the new diagnostic methods (
dvSetsToString,toStringWithIdentityHashCode) and are all utilized in the new code.Also applies to: 23-24, 26-26, 32-32, 37-37, 47-47
2073-2073: LGTM! Typo fix applied consistently.The renaming from
skinyOutputtoskinnyOutputcorrects a spelling error and is consistently applied across all call sites and method definitions.Also applies to: 2088-2088, 2155-2155, 2170-2170, 2194-2237
2243-2255: LGTM! DVSet constructors support diagnostic functionality.The new private constructors provide clean initialization options for DVSet instances used in diagnostic code. Private visibility is appropriate for this inner class.
2273-2286: LGTM! Diagnostic method provides detailed variable representation.The
toStringWithIdentityHashCode()method produces well-formatted, multi-line output suitable for debugging. The implementation correctly usesStringJoinerand delegates toDaikonVariableInfo.toStringWithIdentityHashCode().
2327-2351: LGTM! Java 8 compatible UTF-8 encoding implementation.The method correctly uses
StandardCharsets.UTF_8.name()with the string-basedPrintStreamconstructor for Java 8 compatibility. The comment appropriately notes the simpler Java 11 approach for future reference.Based on learnings, the Java 8 compatibility concern applies to
PrintStream(File, Charset), not thePrintStream(OutputStream, boolean, String)constructor used here.
2310-2310: LGTM! Suppresses logging in diagnostic code.The change to
add_variable_quietly()prevents logging output when building diagnostic comparability sets, which avoids recursive logging issues and keeps diagnostic output clean.
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Fix all issues with AI agents
In @doc/Makefile:
- Around line 6-7: The Makefile adds a CRONIC variable but lacks documentation;
add a one-line comment above the CRONIC assignment explaining its purpose (e.g.,
that CRONIC wraps commands to suppress output unless the command fails, making
CI logs quieter while surfacing errors), so readers understand why CRONIC is
used and what behavior to expect when using the CRONIC variable.
In @java/daikon/dcomp/DCRuntime.java:
- Around line 2483-2499: Re-enable and fix the duplicate-name check around
dest_map/ dest_var in DCRuntime.java instead of using the if(false);
specifically: restore the duplicate-detection block that currently throws an
Error and replace the blind overwrite with a clear handling strategy — either
prevent merging across different program points (validate program-point identity
before inserting into dest_map), convert dest_map to a multimap/list-of-vars
(store multiple DaikonVariableInfo values per name) and update the downstream
merge logic that reads dest_map (the code that uses dest_map.get(...) during the
merge and the DVSet(varlist(dest)) diagnostic) to handle multiple entries, or
implement an explicit merge/selection function that resolves duplicates
deterministically and documents why duplicates are acceptable. Ensure the chosen
fix removes the silent overwrite, logs meaningful context (use
toStringWithIdentityHashCode() / DVSet diagnostics), and adjusts any code paths
that assume a single dest_map entry.
In @java/Makefile:
- Around line 647-649: The root Makefile broke compatibility by renaming the
phony target update-plume-scripts to update-plume-scripts-in-utils; add a
backward-compatible alias by reintroducing a phony target named
update-plume-scripts that simply depends on (invokes)
update-plume-scripts-in-utils so existing callers (CI, scripts, developer
workflows) continue to work; ensure both .PHONY includes update-plume-scripts
and the alias delegates to update-plume-scripts-in-utils (no duplicate
implementation).
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (5)
Makefiledoc/Makefilejava/Makefilejava/daikon/dcomp/DCRuntime.javatests/Makefile.common
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-10-15T17:49:49.294Z
Learnt from: markro49
Repo: codespecs/daikon PR: 685
File: java/daikon/dcomp/DCInstrument.java:0-0
Timestamp: 2025-10-15T17:49:49.294Z
Learning: The PrintStream(File, Charset) constructor was introduced in Java 10. For Java 8 compatibility, use PrintStream(File, String csn) with the string literal "UTF-8" instead of StandardCharsets.UTF_8.
Applied to files:
java/daikon/dcomp/DCRuntime.java
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (11)
- GitHub Check: codespecs.daikon (typecheck_bundled_part2_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_latest_part3_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_latest_part1_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_latest_part2_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (nontxt_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (misc_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part3_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (typecheck_bundled_part1_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (kvasir_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (quick_ubuntu_jdk25)
- GitHub Check: codespecs.daikon (nonquick_ubuntu_jdk25)
🔇 Additional comments (11)
java/daikon/dcomp/DCRuntime.java (4)
21-21: LGTM: New imports support added functionality.The new imports are used by the
dvSetsToString()debugging method (lines 2327-2351) and the newDVSetconstructor (line 2255).Also applies to: 23-24, 26-26, 32-32, 37-37
245-257: LGTM: Private constructors enhance flexibility.The new private constructors provide flexible initialization options for
DVSetinstances while maintaining encapsulation. They're used internally withcomputeIfAbsent(e.g., lines 2386, 2540).
292-293: LGTM: Documentation clarification.The updated javadoc accurately describes when
nullis returned.
2327-2351: LGTM: Well-implemented debugging utility.The
dvSetsToString()method uses Java 8-compatiblePrintStream(OutputStream, boolean, String)constructor. The comment about Java 11 alternatives is helpful for future maintenance. The exception handling is defensive but reasonable since UTF-8 is guaranteed to be supported.tests/Makefile.common (1)
288-288: LGTM: Proper use of MAKE variable.Using
${MAKE}instead of hardcodedmakeensures the correct make binary is invoked and properly propagates make flags to sub-makes.Also applies to: 291-291
doc/Makefile (1)
67-71: LGTM: Consistent migration to .utils/ directory structure.The path updates from
../utils/to../.utils/are systematic and correct. The dependencies ensure these utilities are present before use.Also applies to: 75-75, 81-81, 91-104, 114-118
java/Makefile (1)
12-13: LGTM: Systematic migration to .utils/ directory.The path updates from
${DAIKONDIR}/utils/to${DAIKONDIR}/.utils/are consistent and comprehensive. Dependencies are properly updated to ensure utilities are available before use.Also applies to: 641-645, 671-671, 736-737, 752-752, 839-839, 858-860, 869-869, 1258-1258, 1277-1277, 1291-1291, 1321-1322, 1332-1339, 1433-1433
Makefile (4)
193-195: LGTM: Good backward compatibility handling.The cleanup properly removes both
.utils/and the oldutils/directory, with a helpful comment explaining the old name. This ensures clean migration for existing checkouts.
325-326: LGTM: Appropriate code style exclusions.Adding
.utilsand.plume-scriptsto the exclusions is correct—these are external dependencies that shouldn't be subject to project code style rules.
7-10: LGTM: Comprehensive and systematic utility directory migration.The relocation of external utilities from
utils/to.utils/is consistently applied across all variable definitions and update targets. The hidden directory approach reduces clutter in the project root.Also applies to: 743-806
628-629: Dependency chain is correctly implemented.The
daikon.taranddaikon.ziptargets properly call${MAKE} doc-allbefore verifying file existence with${MAKE} ${DOC_PATHS}. Thedoc-alltarget invokesmake -C doc all, which produces all required documentation files (config-options.texinfo, invariants-doc.texinfo, daikon.pdf, daikon.html, developer.html, developer.pdf, and image files) before the existence check. The${MAKE} ${DOC_PATHS}mechanism verifies these files exist by attempting to make them as targets; missing files will cause the target to fail.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@doc/Makefile`:
- Around line 121-122: The developer.pdf Makefile target still prefixes the
makeinfo command with ${CRONIC}, which triggers undefined-variable failures on
Rocky Linux; update the Makefile so the developer.pdf recipe mirrors the
daikon.pdf recipe by removing the ${CRONIC} prefix from the developer.pdf target
(i.e., stop invoking ${CRONIC} before makeinfo in the developer.pdf rule) so
both PDF targets run makeinfo directly, eliminating the need for
environment-workarounds in CI.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@doc/Makefile`:
- Around line 118-134: For targets daikon.pdf and developer.pdf fix the broken
shell recipe by capturing make's ${CRONIC} into a shell variable, using a single
recipe shell block with proper statement separators (semicolons or &&) after
sourcing /etc/os-release, escaping make from expanding shell parameter
expansions (use $$ID and $${VERSION_ID#9}) and replace the non‑POSIX `==` and
combined test with POSIX `[ "$$ID" = "rocky" ] && [ "$${VERSION_ID#9}" !=
"$${VERSION_ID#9}" ]` style tests (adjust logic as proposed) so the shell can
override CRONIC at runtime; update the lines that reference ${CRONIC} to use the
shell variable instead within that same recipe.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@doc/Makefile`:
- Around line 119-129: The recipe runs multiple separate shells so NO_CRONIC
never persists and the if/else/fi is invalid; fix by collapsing the whole logic
into a single shell invocation using backslashes to join lines, replace
non-POSIX "==" with "=" in the conditional comparing $$ID, quote variables in
tests (e.g. use [ -n "$$NO_CRONIC" ] and compare "$$VERSION_ID" safely), and
ensure ${CRONIC} is declared as a prerequisite/dependency for the target (like
you did for developer.pdf) so the ${CRONIC} variable is available when invoking
makeinfo; reference the NO_CRONIC variable, the $$ID/$$VERSION_ID comparisons,
the ${CRONIC} invocation, and the makeinfo --pdf call to locate changes.
2 participants
No description provided.