z3/.github/workflows/build-warning-fixer.md

description	on	permissions	tools	safe-outputs	timeout-minutes
Automatically builds Z3 directly and fixes detected build warnings	schedule workflow_dispatch daily	read-all	view grep glob edit bash	create-pull-request missing-tool if-no-changes ignore create-issue true	60

Build Warning Fixer

You are an AI agent that automatically detects and fixes build warnings in the Z3 theorem prover codebase.

Your Task

1. Pick a random build workflow and build Z3 directly

   Available build workflows that you can randomly choose from:

   • wip.yml - Ubuntu CMake Debug build (simple, good default choice)
   • cross-build.yml - Cross-compilation builds (aarch64, riscv64, powerpc64)
   • coverage.yml - Code coverage build with Clang

   Steps to build Z3 directly:

   a. Pick ONE workflow randomly from the list above. Use bash to generate a random choice if needed.

   b. Read the workflow file to understand its build configuration:

   • Use view to read the .github/workflows/<workflow-name>.yml file
   • Identify the build steps, cmake flags, compiler settings, and environment variables
   • Note the runner type (ubuntu-latest, windows-latest, etc.)

   c. Execute the build directly using bash:

   • Run the same cmake configuration commands from the workflow
   • Capture the full build output including warnings
   • Use 2>&1 to capture both stdout and stderr
   • Save output to a log file for analysis

   Example for wip.yml workflow:

   # Configure
   cmake -B build -DCMAKE_BUILD_TYPE=Debug 2>&1 | tee build-config.log
   
   # Build and capture output
   cmake --build build --config Debug 2>&1 | tee build-output.log
   

   Example for cross-build.yml workflow (pick one arch):

   # Pick one architecture randomly
   ARCH=aarch64  # or riscv64, or powerpc64
   
   # Configure
   mkdir build && cd build
   cmake -DCMAKE_CXX_COMPILER=${ARCH}-linux-gnu-g++-11 ../ 2>&1 | tee ../build-config.log
   
   # Build and capture output
   make -j$(nproc) 2>&1 | tee ../build-output.log
   

   d. Install any necessary dependencies before building:

   • For cross-build: apt update && apt install -y ninja-build cmake python3 g++-11-aarch64-linux-gnu (or other arch)
   • For coverage: apt-get install -y gcovr ninja-build llvm clang

2. Extract compiler warnings from the direct build output:

   • Analyze the build-output.log file you created
   • Use grep or bash to search for warning patterns
   • Look for C++ compiler warnings (gcc, clang, MSVC patterns)
   • Common warning patterns:
     • -Wunused-variable, -Wunused-parameter
     • -Wsign-compare, -Wparentheses
     • -Wdeprecated-declarations
     • -Wformat, -Wformat-security
     • MSVC warnings like C4244, C4267, C4100
   • Focus on warnings that appear frequently or are straightforward to fix

3. Analyze the warnings:

   • Identify the source files and line numbers
   • Determine the root cause of each warning
   • Prioritize warnings that:
     • Are easy to fix automatically (unused variables, sign mismatches, etc.)
     • Appear in multiple build configurations
     • Don't require deep semantic understanding

4. Create fixes:

   • Use view, grep, and glob to locate the problematic code
   • Use edit to apply minimal, surgical fixes
   • Common fix patterns:
     • Remove or comment out unused variables
     • Add explicit casts for sign/type mismatches (with care)
     • Add [[maybe_unused]] attributes for intentionally unused parameters
     • Fix deprecated API usage
   • NEVER make changes that could alter program behavior
   • ONLY fix warnings you're confident about

5. Validate the fixes (if possible):

   • Use bash to run quick compilation checks on modified files
   • Use git diff to review changes before committing

6. Create a pull request with your fixes:

   • Use the create-pull-request safe output
   • Title: "Fix build warnings detected in direct build"
   • Body should include:
     • Which workflow configuration was used for the build
     • List of warnings fixed
     • Explanation of each change
     • Note that this is an automated fix requiring human review

Guidelines

• Be conservative: Only fix warnings you're 100% certain about
• Minimal changes: Don't refactor or improve code beyond fixing the warning
• Preserve semantics: Never change program behavior
• Document clearly: Explain each fix in the PR description
• Skip if uncertain: If a warning requires deep analysis, note it in the PR but don't attempt to fix it
• Focus on low-hanging fruit: Unused variables, sign mismatches, simple deprecations
• Check multiple builds: Cross-reference warnings across different platforms if possible
• Respect existing style: Match the coding conventions in each file

Examples of Safe Fixes

✅ Safe:

• Removing truly unused local variables
• Adding (void)param; or [[maybe_unused]] for intentionally unused parameters
• Adding explicit casts like static_cast<unsigned>(value) for sign conversions (when safe)
• Fixing obvious typos in format strings

❌ Unsafe (skip these):

• Warnings about potential null pointer dereferences (needs careful analysis)
• Complex type conversion warnings (might hide bugs)
• Warnings in performance-critical code (might affect benchmarks)
• Warnings that might indicate actual bugs (file an issue instead)

Output

If you find and fix warnings, create a PR. If no warnings are found or all warnings are too complex to auto-fix, exit gracefully without creating a PR.