Conversation
📝 WalkthroughWalkthroughAdds a new 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 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: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@build.gradle`:
- Line 763: The etags invocation in the commandLine("etags", ...) call includes
the argument "-i", "buildSrc/TAGS" twice; remove the duplicate "-i",
"buildSrc/TAGS" entry from that commandLine invocation so each TAGS path is only
listed once (locate the commandLine("etags", ...) call and delete the redundant
"buildSrc/TAGS" pair).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 49cf72ac-8f6e-4103-8f25-7875990063e4
📒 Files selected for processing (1)
build.gradle
|
The problem is that rm -f TAGS; find . -type f -name '\''*.java'\'' -print0 | xargs -0 etags -athough making it more uniform with the other subprojects would be better. |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@buildSrc/build.gradle`:
- Line 5: The applied tags.gradle in buildSrc registers a tags task inside the
buildSrc build that will not be run by ./gradlew tags at the repo root, so
either (A) remove the apply from buildSrc and make the root-level tags task
produce/refresh buildSrc/TAGS by running a shell step that cds into buildSrc and
regenerates TAGS (so the root task truly covers buildSrc files), or (B) keep the
buildSrc tags implementation but add a root-level bridge task that invokes
buildSrc's tags using a GradleBuild (e.g. register a "buildSrcTags" GradleBuild
that sets dir to "buildSrc" and tasks = ["tags"] and then make the root "tags"
task dependOn that bridge), ensuring buildSrc/TAGS is produced when running
./gradlew tags; update build scripts to remove the current apply from buildSrc
if you choose approach A.
In `@buildSrc/src/main/groovy/tags.gradle`:
- Around line 1-5: Update the "tags" task to set group = "Emacs" and make the
etags invocation safe against ARG_MAX truncation: before running etags remove
any existing TAGS (rm -f TAGS) and invoke etags in append mode (-a) so multiple
xargs batches accumulate instead of overwriting; use NUL-delimited find/xargs
(find -print0 | sort-directory-order -z | xargs -0 etags -a) if your
sort-directory-order supports -z, otherwise keep the rm -f TAGS + etags -a
pattern with the existing whitespace-delimited pipeline to ensure all batches
are appended.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 59ffbaba-8fc1-4f5a-ade7-3fa26928fe5d
📒 Files selected for processing (3)
build.gradlebuildSrc/build.gradlebuildSrc/src/main/groovy/tags.gradle
| tasks.register("tags", Exec) { | ||
| description = "Create Emacs TAGS table" | ||
| // `ctags -e -f TAGS` used to work in place of `etags`, but apparently no longer. | ||
| commandLine("bash", "-c", "find . \\( -name build -o -name jtreg -o -name tests \\) -prune -o -name '*.java' -print | sort-directory-order | xargs etags") | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Does GNU etags overwrite the TAGS file on each invocation by default, and does the -a/--append flag cause it to append instead?
💡 Result:
Yes, GNU etags overwrites the TAGS file on each invocation by default. Without the -a/--append flag, it creates a new TAGS file (default name) containing tags only from the specified input files. The -a/--append flag causes it to append new tags to an existing TAGS file instead of overwriting it.
Citations:
- 1: https://www.gnu.org/software/emacs/manual/html_node/emacs/Create-Tags-Table.html
- 2: https://leancrew.com/all-this/man/man1/etags.html
- 3: https://man.archlinux.org/man/etags.1.en
- 4: https://man.cx/etags(1)
🏁 Script executed:
# Verify the actual file exists and check its content
find . -path "*/buildSrc/src/main/groovy/tags.gradle" -type fRepository: typetools/checker-framework
Length of output: 109
🏁 Script executed:
# Search for the root build.gradle and look for tags/docTags task definitions
find . -maxdepth 2 -name "build.gradle" -type f | head -20Repository: typetools/checker-framework
Length of output: 369
🏁 Script executed:
# Search for references to "group = " in build.gradle files to confirm Emacs group
rg "group\s*=\s*[\"']Emacs[\"']" --type groovy -B 2 -A 2Repository: typetools/checker-framework
Length of output: 842
🏁 Script executed:
# Check if sort-directory-order is defined in the repository
rg "sort-directory-order" --type groovy --type sh --type bashRepository: typetools/checker-framework
Length of output: 99
🏁 Script executed:
# Read the actual tags.gradle file to confirm the code snippet
cat -n ./buildSrc/src/main/groovy/tags.gradleRepository: typetools/checker-framework
Length of output: 421
🏁 Script executed:
# Search for sort-directory-order without type specification
rg "sort-directory-order" -A 3 -B 3Repository: typetools/checker-framework
Length of output: 571
🏁 Script executed:
# Check if there's a sort-directory-order script/executable in the repo
fd "sort-directory-order" -type fRepository: typetools/checker-framework
Length of output: 241
🏁 Script executed:
# Search for sort-directory-order anywhere in the repo
rg "sort-directory-order"Repository: typetools/checker-framework
Length of output: 264
🏁 Script executed:
# Check if it's defined in plume-scripts or is an external utility
rg "def sort-directory-order" -A 5Repository: typetools/checker-framework
Length of output: 53
🏁 Script executed:
# Look for where plume-scripts or similar utilities are sourced
rg "plume" --max-count 10Repository: typetools/checker-framework
Length of output: 50383
🏁 Script executed:
# Check the root build.gradle for how the tags task incorporates subproject tags
cat -n ./build.gradle | grep -A 20 "tasks.register.*tags"Repository: typetools/checker-framework
Length of output: 1059
🏁 Script executed:
# Check if there's documentation or implementation of sort-directory-order in plume-scripts
rg "sort-directory-order" -A 10 -B 2 | head -50Repository: typetools/checker-framework
Length of output: 503
🏁 Script executed:
# Look for any test or usage examples of sort-directory-order with -z flag
rg "\-print0\|\-0\|\s-z\s" --max-count 20Repository: typetools/checker-framework
Length of output: 53
🏁 Script executed:
# Check if the plume-scripts repo or reference is present
ls -la checker/bin-devel/.plume-scripts 2>/dev/null || echo "plume-scripts not checked out"Repository: typetools/checker-framework
Length of output: 100
🏁 Script executed:
# Verify the actual impact by checking the sizes of source trees in affected subprojects
find checker/src -name "*.java" | wc -l
find framework/src -name "*.java" | wc -l
find dataflow/src -name "*.java" | wc -lRepository: typetools/checker-framework
Length of output: 82
Add group = "Emacs" and fix xargs truncation hazard in the tags task.
Two issues:
-
xargs can truncate TAGS on large subprojects. When the Java file list exceeds
ARG_MAX,xargsinvokesetagsmultiple times; sinceetagsoverwrites the TAGS file by default, only the last batch's entries survive. This plugin is now applied to all non-checker-qual-androidsubprojects (checker,framework,dataflow, etc.), some of which may plausibly exceed the limit when combined. Userm -f TAGS; find … | xargs etags -ato start fresh and append instead. -
Missing
groupdeclaration. The rootbuild.gradleassignsgroup = "Emacs"to both thetagsanddocTagstasks. Add it here for consistency.
Proposed fix
tasks.register("tags", Exec) {
description = "Create Emacs TAGS table"
+ group = "Emacs"
// `ctags -e -f TAGS` used to work in place of `etags`, but apparently no longer.
- commandLine("bash", "-c", "find . \\( -name build -o -name jtreg -o -name tests \\) -prune -o -name '*.java' -print | sort-directory-order | xargs etags")
+ commandLine("bash", "-c", "rm -f TAGS && find . \\( -name build -o -name jtreg -o -name tests \\) -prune -o -type f -name '*.java' -print0 | sort-directory-order -z | xargs -0 etags -a")
}Note: Verify that your sort-directory-order supports the -z flag for NUL-delimited input. If not, omit -print0, -0, and -z, but keep the rm -f TAGS + etags -a pair, which is the critical fix.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@buildSrc/src/main/groovy/tags.gradle` around lines 1 - 5, Update the "tags"
task to set group = "Emacs" and make the etags invocation safe against ARG_MAX
truncation: before running etags remove any existing TAGS (rm -f TAGS) and
invoke etags in append mode (-a) so multiple xargs batches accumulate instead of
overwriting; use NUL-delimited find/xargs (find -print0 | sort-directory-order
-z | xargs -0 etags -a) if your sort-directory-order supports -z, otherwise keep
the rm -f TAGS + etags -a pattern with the existing whitespace-delimited
pipeline to ensure all batches are appended.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@build.gradle`:
- Around line 767-769: The root-level tags aggregation can run before buildSrc's
TAGS is generated; update the root "tags" task (the one currently depending on
"docTags" and invoking commandLine that reads buildSrc/TAGS) to also depend on
buildSrc:tags (or add a wrapper task that depends on
project(':buildSrc').tasks.named('tags') and then make the root "tags" depend on
that wrapper) so that buildSrc/TAGS is always produced before the commandLine
references it; ensure you reference the existing "tags" task, the "docTags"
dependency, and the buildSrc:tags task name when adding the dependency.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: c01da588-394b-43f0-be03-26b2a64882f6
📒 Files selected for processing (1)
build.gradle
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@build.gradle`:
- Around line 754-759: The buildSrcTags task currently passes multiple arguments
to bash -c so only "cd" is run; update the buildSrcTags task to run the whole
find/etags script as a single shell script (or set workingDir = file("buildSrc")
and run the find/etags pipeline via a single bash -c string) so the find and
etags commands actually execute; also change the task description to distinguish
it from the root aggregator's "tags" task and align the command shape with the
subproject tags task (refer to the buildSrcTags task and the root/subproject
tags tasks) to ensure buildSrc/TAGS is generated and consumed correctly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: d6ae7058-9c08-4875-9b2a-d62bedec36a0
📒 Files selected for processing (1)
build.gradle
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
build.gradle (2)
762-768: 🧹 Nitpick | 🔵 TrivialQuote task names in
dependsOnfor consistency.Elsewhere in this file
dependsOnis called with string task names (e.g. Line 611, 708, 1085). HeredependsOn(docTags, buildSrcTags)relies on the implicit task-as-property lookup, which works since both are registered above but is stylistically inconsistent with the rest of the build script.♻️ Proposed change
- dependsOn(docTags, buildSrcTags) + dependsOn("docTags", "buildSrcTags")🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@build.gradle` around lines 762 - 768, The dependsOn call for the "tags" task is using property references (docTags, buildSrcTags) instead of string task names; update the dependsOn invocation in the tasks.register("tags", Exec) block to use quoted task names (e.g. "docTags", "buildSrcTags") to match the rest of the build script's style and avoid implicit property lookup.
762-768:⚠️ Potential issue | 🟠 MajorAdd explicit
dependsOnfor subprojecttagstasks to ensure deterministic ordering.The root
tagstask references TAGS files from multiple subprojects (checker,dataflow,framework, etc.) via thecommandLine, but only explicitly depends ondocTagsandbuildSrcTags. While the comment claims subprojecttagstasks will run via Gradle's task-name matching, this doesn't guarantee they execute before the root task'setagsmerge—causing the merge to potentially include stale content.Since
buildSrcTagsis already explicitly wired viadependsOnfor consistency, extend this pattern to the other subprojecttagstasks to ensure deterministic execution order.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@build.gradle` around lines 762 - 768, The root Gradle task "tags" currently only dependsOn(docTags, buildSrcTags) but relies on subproject "tags" tasks implicitly; add explicit dependsOn entries for each subproject tags task (e.g., ":checker:tags", ":checker-qual:tags", ":checker-util:tags", ":dataflow:tags", ":framework:tags", ":framework-test:tags", ":javacutil:tags", ":docs:tags" or the exact project path names matching the TAGS listed) so those tasks run before the root "tags" Exec task that runs commandLine("etags", ...); update the dependsOn(...) call on the "tags" task to include docTags, buildSrcTags and all the subproject ":<project>:tags" task references to guarantee deterministic ordering.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@build.gradle`:
- Around line 762-768: The dependsOn call for the "tags" task is using property
references (docTags, buildSrcTags) instead of string task names; update the
dependsOn invocation in the tasks.register("tags", Exec) block to use quoted
task names (e.g. "docTags", "buildSrcTags") to match the rest of the build
script's style and avoid implicit property lookup.
- Around line 762-768: The root Gradle task "tags" currently only
dependsOn(docTags, buildSrcTags) but relies on subproject "tags" tasks
implicitly; add explicit dependsOn entries for each subproject tags task (e.g.,
":checker:tags", ":checker-qual:tags", ":checker-util:tags", ":dataflow:tags",
":framework:tags", ":framework-test:tags", ":javacutil:tags", ":docs:tags" or
the exact project path names matching the TAGS listed) so those tasks run before
the root "tags" Exec task that runs commandLine("etags", ...); update the
dependsOn(...) call on the "tags" task to include docTags, buildSrcTags and all
the subproject ":<project>:tags" task references to guarantee deterministic
ordering.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 41353d33-e6e6-4d93-b0d6-540fa494af98
📒 Files selected for processing (1)
build.gradle
2 participants
No description provided.