esp32: `misc/rge_sm.py` test fails with hardware floating point enabled.
Port, board and/or hardware
generic esp32 board with ESP32_GENERIC
MicroPython version
MicroPython v1.26.0-preview.148.g49f81d504.dirty on 2025-05-25; Generic ESP32 module with ESP32
Reproduction
- Build the current
master(49f81d5046aaeb31f90626426363ae2518dbd810) ESP32 port with hard floating point support enabled (forceMICROPY_OBJ_REPRset toMICROPY_OBJ_REPR_CandMICROPY_FLOAT_IMPLset toMICROPY_FLOAT_IMPL_FLOAT) - Flash the firmware on the board and run the test suite
misc/rge_smtest will fail.
Expected behaviour
tests/misc/rge_sm.py should not fail with hard floating point support enabled.
Observed behaviour
The test output is attached:
Additional Information
Maybe the test should be rewritten using unittest.assertAlmostEqual to perform the value comparisons instead of relying on rounding behaviour.
I'm aware I'm trying out an uncommon object representation for the target in question, but I wonder if other MCUs with hardware floating point also exhibit the same test failure since the test relies on how float rounding is performed to pass.
Code of Conduct
Yes, I agree
Passing tests reported as failures with `MICROPY_ERROR_REPORTING_TERSE`
Port, board and/or hardware
Any
MicroPython version
MicroPython v1.26.0-preview.386.g17fbc5abd.dirty
Reproduction
- Clean build your port of choice
- Run the test suite, notice the absence of failures
- Add
#define MICROPY_ERROR_REPORTING (MICROPY_ERROR_REPORTING_TERSE)to your port'smpconfigport.hfile - Clean build the port
- Run the test suite again.
Expected behaviour
All tests that were passing before changing the error reporting level should still pass.
Observed behaviour
I've seen the following tests fail (for example on QEMU/RV32):
micropython/heapalloc_exc_compressed.pymicropython/heapalloc_exc_compressed_emg_exc.pymicropython/native_with.pymicropython/opt_level_lineno.pymicropython/viper_with.pymisc/print_exception.py
Probably there are more of these but are port-specific and haven't encountered them yet.
Additional Information
The issue is that those tests perform an exact string match on the exception message being raised by the interpreter. With the error reporting level changing, the exception message may change, and thus fail perfectly working tests.
I see this issue on a custom port I'm doing where, for space reasons, I've got to keep error reporting verboseness down. This means I cannot get a single clean test run because with the extra space taken by the error messages (and their interpolation) I have to cut out other features to fit things in the allotted flash space.
A similar issue also exists, as in it's not possible to have a clean test run with the port's ROM level set to MICROPY_CONFIG_ROM_LEVEL_MINIMUM as some tests (even in basic) depend on features cut out by that definition.
I don't mind cleaning up those tests to have a more comprehensive pass/fail check and eventually migrate them to unittest if that's required (and putting in the work to make it testable with the minimum feature set, whilst I'm here...), but before starting this I wonder if this is a PR (or multiple PRs, who knows) that will be at least considered for inclusion.
Code of Conduct
Yes, I agree