[self-tests] mypyc 1.15.0 self-tests fail

[stanislavlevin]

Bug Report

mypyc 1.15.0 self-tests fail with CFLAGS -Wall.

To Reproduce

$ export CFLAGS='-Wall'
$ python -m pytest -ra mypyc/test

Expected Behavior

Tests should pass without failures.

Actual Behavior

FAILED mypyc/test/test_run.py::TestRun::run-bools.test::testBoolOps
FAILED mypyc/test/test_run.py::TestRun::run-i64.test::testI64BasicOps
FAILED mypyc/test/test_run.py::TestRun::run-i64.test::testI64ErrorValuesAndUndefined
FAILED mypyc/test/test_run.py::TestRun::run-i64.test::testI64DefaultArgValues
FAILED mypyc/test/test_run.py::TestRun::run-i64.test::testI64GlueMethodsAndInheritance
========== 5 failed, 1182 passed, 1 skipped, 2 xfailed

An example of failure report:

__________________________ testI64GlueMethodsAndInheritance __________________________
[gw3] linux -- Python 3.12.8 /usr/src/RPM/BUILD/python3-module-mypy-1.15.0/.run_venv/bin/python3
data: /usr/src/RPM/BUILD/python3-module-mypy-1.15.0/mypyc/test-data/run-i64.test:1340:
Failed: Invalid output (/usr/src/RPM/BUILD/python3-module-mypy-1.15.0/mypyc/test-data/run-i64.test, line 1340)
-------------------------------- Captured stdout call --------------------------------

*** Exit status: -6
-------------------------------- Captured stderr call --------------------------------
Expected:
Actual:
  python3: /usr/include/python3.12/object.h:231: Py_SIZE: Assertion `ob->ob_type != &PyLong_Type' failed. (diff)

Update the test output using --update-data (implies -n0; you can additionally use the -k selector to update only specific tests)
--------------------------------- Captured log call ----------------------------------
INFO     root:dist.py:999 running build_ext
INFO     root:build_ext.py:535 building 'native' extension
INFO     root:dir_util.py:58 creating build/temp.linux-x86_64-cpython-312/build
INFO     root:spawn.py:60 x86_64-alt-linux-gcc -Wall -fPIC -I/usr/src/RPM/BUILD/python3-module-mypy-1.15.0/mypyc/lib-rt -I/usr/src/RPM/BUILD/python3-module-mypy-1.15.0/.run_venv/include -I/usr/include/python3.12 -c build/__native.c -o build/temp.linux-x86_64-cpython-312/build/__native.o -O0 -g1 -Werror -Wno-unused-function -Wno-unused-label -Wno-unreachable-code -Wno-unused-variable -Wno-unused-command-line-argument -Wno-unknown-warning-option -Wno-unused-but-set-variable -Wno-ignored-optimization-argument -Wno-cpp
INFO     root:dir_util.py:58 creating build/lib.linux-x86_64-cpython-312
INFO     root:spawn.py:60 x86_64-alt-linux-gcc -shared -Wall build/temp.linux-x86_64-cpython-312/build/__native.o -L/usr/lib64 -o build/lib.linux-x86_64-cpython-312/native.cpython-312.so
INFO     root:file_util.py:130 copying build/lib.linux-x86_64-cpython-312/native.cpython-312.so ->

Your Environment

• Mypy version used: 1.15.0
• Python version used: 3.12.8

[wesleywright]

We don't support compiling with -Wall; mypyc intentionally disables some warnings, so it's known that warnings will exist in some of the code.

I also see the same behavior on previous versions of mypy (at least 1.13 and 1.14.1). How did you run into this/what was your use case for running these tests with -Wall?

[stanislavlevin]

We don't support compiling with -Wall; mypyc intentionally disables some warnings, so it's known that warnings will exist in some of the code.

Can I find the docs please?

I also see the same behavior on previous versions of mypy (at least 1.13 and 1.14.1).

This is the first release affected by set CFLAGS (tested since mypy 1.0.1).

How did you run into this/what was your use case for running these tests with -Wall?

I'm packaging mypy for one of the Linux distros for long time.
RPM macro utilized to run the tests sets -Wall.

[wesleywright]

This is the first release affected by set CFLAGS (tested since mypy 1.0.1).

This conflicts with what I'm seeing on my system; I just double checked, and the tests pass by default and then fail with CFLAGS=-Wall for multiple versions before 1.15. That said, I'm on macOS 13.7.3, which is probably a very different environment than yours.

On that point, I think the general problem with trying to support -Wall is that it's not standardized across different environments. Different compilers (and different versions of each compiler) can modify which warnings they include, as well as what warnings are detected for a given file. For example, you can see the differences between -Wall on GCC 13.3 and -Wall on GCC 14.2 on their official website.

Can I find the docs please?

Sadly I don't think we have existing docs for this, but there's a very large number of C compiler flags that may or may not have odd effects when used with mypyc code (or with any project). I don't know that it's feasible to document that exhaustively.

I'm packaging mypy for one of the Linux distros for long time. RPM macro utilized to run the tests sets -Wall.

Is it possible to weaken that setting for your RPM spec file (or manually override CFLAGS in the spec file to remove -Wall)? I don't have any spec file examples on hand, but my instinct is that this is probably a common practice (a lot of very popular open source projects sadly emit tons of compiler warnings).

[stanislavlevin]

This is the first release affected by set CFLAGS (tested since mypy 1.0.1).

This conflicts with what I'm seeing on my system; I just double checked, and the tests pass by default and then fail with CFLAGS=-Wall for multiple versions before 1.15. That said, I'm on macOS 13.7.3, which is probably a very different environment than yours.

gcc 14.2.1 here but distros started to switch to gcc 15

On that point, I think the general problem with trying to support -Wall is that it's not standardized across different environments. Different compilers (and different versions of each compiler) can modify which warnings they include, as well as what warnings are detected for a given file. For example, you can see the differences between -Wall on GCC 13.3 and -Wall on GCC 14.2 on their official website.

It's up to the project how to treat the warnings. My goal was to pay upstream's attention to this potential problem.

Can I find the docs please?

Sadly I don't think we have existing docs for this, but there's a very large number of C compiler flags that may or may not have odd effects when used with mypyc code (or with any project). I don't know that it's feasible to document that exhaustively.

I'm packaging mypy for one of the Linux distros for long time. RPM macro utilized to run the tests sets -Wall.

Is it possible to weaken that setting for your RPM spec file (or manually override CFLAGS in the spec file to remove -Wall)? I don't have any spec file examples on hand, but my instinct is that this is probably a common practice (a lot of very popular open source projects sadly emit tons of compiler warnings).

Sure, I can hack it in the way to get the tests passed.

[eli-schwartz]

It seems weird that the tests should fail when passing a flag that has no effect on codegen, but only prints warnings during compilation. It's just a linter.

That being said, it also feels a bit weird for a distro to set this globally

[stanislavlevin]

Rechecked,
the issue is triggered by setuptools 75.7.0+ and it's not related to the version of mypyc:
https://setuptools.pypa.io/en/stable/history.html#v75-7-0

pypa/distutils#322

Since 2c93711, CXXFLAGS is used as-is if set in the envionment rather than clobbered by whatever CPython happened to be built with.
Do the same for CFLAGS: use it as-is if set in the environment, don't prepend CPython's saved flags.

With that version of setuptools CFLAGS overrides the CPython's one. In my case one of the overridden values is NDEBUG. Missing -DNDEBUG in CFLAGS enables assertions.

[eli-schwartz]

Even before that setuptools change it was possible to validate mandatory preconditions in a setuptools C extension if you have configured cpython to validate its own mandatory preconditions too. But very few people test debug builds of cpython, for some reason.

[eli-schwartz]

I'm also vaguely surprised that Alt Linux is passing -Wall in CFLAGS but not e.g. -march=x86-64 -mtune=generic -O2 -pipe -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fstack-clash-protection -fcf-protection -frecord-gcc-switches

Not even targeted errors such as -Wformat -Werror=format-security -Werror=strict-aliasing -Werror=odr -Werror=lto-type-mismatch