-
-
Notifications
You must be signed in to change notification settings - Fork 8.3k
Test REPR_B & fix test failures #17688
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #17688 +/- ##
=======================================
Coverage 98.44% 98.44%
=======================================
Files 171 171
Lines 22208 22215 +7
=======================================
+ Hits 21863 21870 +7
Misses 345 345 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Code size report:
|
Native & viper tests fail if --via-mpy even after accounting for small int size. I did some digging and I'm guessing it's because mpy-cross uses a fixed representation for integers in the code emitter, e.g.,
I chose to simply skip running any of the "native" tests, even though locally they succeed when not going via mpy. Because this was the easiest of the choices available. |
5a8c677
to
5dcf5fa
Compare
I'd prefer not to add this constant, if we can help it. Could the tests automatically detect the max int? Note there is already If we do need to add a constant, it might be better as |
The field encodings for OBJ_REPR_B need to be slightly different than for other representations, as there are only 30 bits (rather than 31) available for small integers. This accounts for about half of all the test failures with an OBJ_REPR_B build, using a commandline like (wrapped): ``` make -j$(nproc) -C ports/unix/ VARIANT=coverage \ MICROPY_FORCE_32BIT=1 \ CFLAGS_EXTRA="-DMICROPY_OBJ_REPR=MICROPY_OBJ_REPR_B \ -Dmp_int_t=int32_t -Dmp_uint_t=uint32_t" test ``` I also added some compile time assertions that the values "should work". For instance, the assertions about about `!VALUE_MASK` are intended to check that bits from the field type do not leak into the offset part. Signed-off-by: Jeff Epler <jepler@gmail.com>
I reworked it to not require the added property. |
is this a known-to-be-flaky test? My changes shouldn't have touched it. |
Yes, it's known flaky. PR #17655 works around the issue. |
Different results are needed for different integer sizes. Signed-off-by: Jeff Epler <jepler@gmail.com>
Signed-off-by: Jeff Epler <jepler@gmail.com>
Signed-off-by: Jeff Epler <jepler@gmail.com>
The check for 'fits in a small int' is specific to the 31-bit int of other OBJ_REPRs. Signed-off-by: Jeff Epler <jepler@gmail.com>
This showed up some interesting errors (hopefully all fixed now). Signed-off-by: Jeff Epler <jepler@gmail.com>
The one remaining failure appears to be |
Summary
For m68k-micropython I'm interested in REPR_B. However, CI doesn't check any REPR_B builds, so of course there were test failures.
This patch series adds a 32-bit REPR_B build (i686 Linux) and fixes the test failures that arose.
Testing
I ran the tests locally with a REPR_B build. I'll check the CI for other failures.
Trade-offs and Alternatives
Just for the benefit of one test in the testsuite, I added
micropython.small_int_max
. Instead, a few tests could be changed so that they just use numbers sized to work on "any repr that gets tested".