Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.38%. Comparing base (22deeeb) to head (bd413d3).
⚠️ Report is 4 commits behind head on master.

@@           Coverage Diff           @@
##           master   #17946   +/-   ##
=======================================
  Coverage   98.38%   98.38%           
=======================================
  Files         171      171           
  Lines       22297    22297           
=======================================
  Hits        21938    21938           
  Misses        359      359           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:   +16 +0.004% PYBV10
     mimxrt:   +16 +0.004% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:   +16 +0.006% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

Incidentally, when testing this I found out the micropython/viper_ptrX_store_boundary.py tests aren't aware of tests/run-tests.py ability to detect large tests. I guess I'd have to rewrite those three tests using unittest and bake in the expected results in the test files themselves.

This SKIP-TOO-LARGE option is a very new feature. Feel free to adjust those tests to properly skip when out-of-memory (although I don't think they need to be unittest tests, that would make them use even more memory).

This SKIP-TOO-LARGE option is a very new feature. Feel free to adjust those tests to properly skip when out-of-memory (although I don't think they need to be unittest tests, that would make them use even more memory).

Right now those tests generate compiled blocks on the fly, which makes them fail in the middle of execution on low-memory platforms (ie. ESP8266 without a prologue file that maps some flash into IRAM). unittest has the ability to either split a single test file into separate cases that may or may not be skipped on their own, or even provide subtests (in this case the address width in bits) for a single fixture.

I can look into making the test generate all compiled blocks upfront so it would fail right away and not require unittest for a clean run on the 8266, but it may make those tests more complex than they are now. Still, thanks for the remark, I'll see what I can do with this!

My preference is always to keep things simple if possible (but at the same time be pragmatic).

And it would actually be good to improve these viper ptr tests, because I'm seeing them fail on small boards like ADAFRUIT_ITSYBITSY_M0_EXPRESS, eg see this Octoprobe output: https://reports.octoprobe.org/github_selfhosted_testrun_255/RUN-TESTS_STANDARD,a@5f2a-ADA_ITSYBITSY_M0/micropython_viper_ptr8_store_boundary.py.out