feat(errorprone): enable production-only safety checks

[halibobo1205]

User description

What does this PR do?

Expands Error Prone checks for production code only.

• Enables BigDecimalFloatingPointConstructor, SelfAssignment, and ForbidJavaLangMath.
• Adds high-signal Error Prone checks and enables:
  • IntLongMath
  • LockNotBeforeTry
  • MissingCasesInEnumSwitch
  • CatchAndPrintStackTrace
• Applies Error Prone only to compileJava; compileTestJava remains excluded.
• Fixes the ReceiveDescriptionCapsule self-assignment issue.
• Replaces direct printStackTrace() calls with structured logging.
• Removes the unused PedersenHashCapsule.main debug entry point.
• Keeps the existing Math CI workflow as a safeguard.

Why are these changes required?

Several correctness and maintainability issues were previously detected only by review or after PR CI ran. In particular, java.lang.Math was checked solely by CI, so contributors could not discover violations during local compilation.

Running these checks during production compilation gives earlier feedback while avoiding a broad cleanup of existing test code.

This PR has been tested by:

• ./gradlew compileJava --rerun-tasks
• ./gradlew compileTestJava -x :framework:generateGitProperties --rerun-tasks
• ./gradlew :errorprone:test checkstyleMain -x :framework:generateGitProperties
• git diff --check

Follow up

Consider enabling additional Error Prone rules after their existing production baselines are reviewed and cleaned up:

• ReturnValueIgnored
• InterruptedExceptionSwallowed
• ReferenceEquality
• WaitNotInLoop
• NarrowCalculation

Extra details

The existing .github/workflows/math-check.yml workflow is intentionally retained as CI-level defense in depth.

---

CodeAnt-AI Description

Enforce deterministic calculations and contract-safe ordering in production code

What Changed

• Production builds now reject direct java.lang.Math usage and floating-point BigDecimal constructors, while allowing deterministic alternatives.
• Store results now sort reliably, including correct tie handling for exchanges, proposals, and assets; equal-expiration proposals preserve the final live-execution value.
• Fixed integer arithmetic cases that could overflow before being widened to long.
• Replaced direct stack-trace printing with structured logging and removed an unused debug entry point.
• Added handling for unrecognized frozen-resource types and fixed PBFT lock acquisition before cache and message verification.
• Added regression tests for ordering, equal-expiration proposal history, and the new compile-time safety checks.

Impact

✅ Deterministic calculations across platforms
✅ Fewer transaction and proposal ordering failures
✅ Safer production builds

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.

[codeant-ai]

🤖 CodeAnt AI — Review Status

Status	Commit	Started (UTC)	Finished (UTC)
✅ Incremental review completed	daf71a0	Aug 10, 2026 · 12:15	12:16
✅ Reviewed your PR	8e90ade	Aug 07, 2026 · 10:40	10:45

[codeant-ai]

---

Thanks for using CodeAnt! 🎉

We're free for open-source projects. if you're enjoying it, help us grow by sharing.

Share on X ·
Reddit ·
LinkedIn

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8e90ade215

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Run the new safety checks for x86 builds

These checks are added inside the existing javaVersion.isJava11Compatible() block, but this repository requires Java 8 when os.arch is x86/amd64, so production compilation on the Rocky Linux/JDK 8 path never applies any of the newly enabled checks. Consequently, x86 contributors can still compile floating-point BigDecimal constructors, self-assignments, and direct Math calls successfully; add a JDK 11+ verification/toolchain task that also runs for x86 sources rather than relying solely on the architecture-gated compileJava configuration.

Useful? React with 👍 / 👎.

[codeant-ai]

Suggestion: The subtraction is performed before clamping the number of items, so malformed short calldata produces a negative count for ValidateMultiSign (for example, zero-length input yields -1) and a zero count for short BatchValidateSign input. In Program, any non-positive required energy bypasses the requiredEnergy > suppliedEnergy check, allowing malformed calls to proceed without being charged for the precompile. Clamp the count to a non-negative value or reject malformed calldata before calculating energy. [incorrect condition logic]

Severity Level: Major ⚠️

- ⚠️ Malformed multisignature calls bypass required-energy accounting.
- ❌ Legacy malformed decoding can fail during VM precompile execution.

(Use Cmd/Ctrl + Click for best experience)

Prompt for AI Agent 🤖

This is a comment left during a code review.

**Path:** actuator/src/main/java/org/tron/core/vm/PrecompiledContracts.java
**Line:** 1046:1046
**Comment:**
	*Incorrect Condition Logic: The subtraction is performed before clamping the number of items, so malformed short calldata produces a negative count for `ValidateMultiSign` (for example, zero-length input yields `-1`) and a zero count for short `BatchValidateSign` input. In `Program`, any non-positive required energy bypasses the `requiredEnergy > suppliedEnergy` check, allowing malformed calls to proceed without being charged for the precompile. Clamp the count to a non-negative value or reject malformed calldata before calculating energy.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix

👍 | 👎

[codeant-ai]

---

Thanks for using CodeAnt! 🎉

We're free for open-source projects. if you're enjoying it, help us grow by sharing.

Share on X ·
Reddit ·
LinkedIn