Set checks_level=0 on linux-meson-clang-tests build

[kazarmy]

Your checklist for this pull request

• I've read the guidelines for contributing to this repository.
• I made sure to follow the project's coding style.
• I've documented every RZ_API function and struct this PR changes.
• I've added tests that prove my changes are effective (required for changes to RZ_API).
• I've updated the Rizin book with the relevant information (if needed).

Detailed description

This pr sets checks_level to 0 on the linux-meson-clang-tests build. This is just to guard against side-effects in code being asserted by rz_assert.h macros. This kind of problem should be easy to fix, so it should be ok that the linux-meson-clang-tests build is not run on every pr.

Test plan

The change makes sense. The linux-meson-clang-tests build is green.

Closing issues

...

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 44.88%. Comparing base (d53c920) to head (f76978d).
Report is 1 commits behind head on dev.

Additional details and impacted files

see 7 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d53c920...f76978d. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Rot127]

What were the side effects you encountered?
Because we would miss ASAN problems in the assert statements itself this way, right?

[kazarmy]

What were the side effects you encountered?

An example of problematic side-effect code is the original code in this diff ... checks_level=0 will simply remove the first argument of rz_return_val_if_fail() as if it didn't exist, and thus the conversion of RL78 operand to string does not happen, resulting in test failures like this:

(https://github.com/rizinorg/rizin/actions/runs/14774758066/job/41480902215#step:18:15463)

This is not an assertion failure and thus checks_level=3 will not catch this.

Because we would miss ASAN problems in the assert statements itself this way, right?

The ASAN builds are still built with checks_level=2 so no removal of code will be done (and they probably will never be built with checks_level=0 since they are debugoptimized builds). This pr doesn't touch the ASAN builds.

[Rot127]

This pr doesn't touch the ASAN builds.

Was on the go and misread it.
Thanks. All good.