Add musllinux wheel support, Use 'official' llvm build for compilation

[ben9923]

Description

This PR has a couple of goals:

1. Adding musllinux mypy wheels, for more users to enjoy mypyc's performance improvements.
2. Eliminating use of an old custom-built clang used in CI (incompatible with newer manylinux images?).
   Upgrades custom clang 6.0.1 to redhat-provided 7.0.1.
3. Building manylinux2014 wheels instead of EOL manylinux2010. Those users will switch to non-compiled releases.

Note For Merging

As available llvm versions are tied to the OS release, cibuildwheel needs to be updated to v2.3+ (Which defaults to manylinux2014) to keep yum install working.
As for musllinux, cibuildwheel needs to be updated to v2.2+.
This PR should handle both by upgrading to the latest release, but needs to be merged at the same time to not break builds:
mypyc/mypy_mypyc-wheels#40

Related to mypyc/mypy_mypyc-wheels#34

Test Plan

Build & Tests

Invoked mypyc CI matrix for all supported platforms, it appears to fully pass :)
https://github.com/ben9923/mypy_mypyc-wheels/actions/runs/2722183433

Wheel Compatibility

To make sure clang upgrade did not break compatibility with manylinux2014 distros (by linking with too new glibc or something), I tested built wheels with some of them (compatible distros listed here).
All of the following seem to work well: CentOS 7, CentOS 8, Fedora 32, Photon 4.0, Ubuntu 20.04, Debian 11.
For musl, tested: Alpine 3.10, Alpine 3.12, Alpine 3.16.

musllinux Performance

musllinux wheels seem to have a similar performance boost to manylinux.
Invoked mypy on the fastapi repo with universal & platform-specific wheels, and it had a similar ~7.5s vs. ~2s time difference across those two platforms, on my local machine.

[hauntsaninja]

Thank you for improving this!

If I could bait you into doing a little more work...
This script was moved to the mypy repo from https://github.com/mypyc/mypy_mypyc-wheels a while back and I think that was the wrong decision, since it's now much harder to validate changes (as you allude to here: mypyc/mypy_mypyc-wheels#40).

How would you feel about moving it back? This would then make reviewing this PR and handling the merges trivial :-)

[hauntsaninja]

Well your fork run is pretty convincing, so I'll just do the double merge and everything should work. We can move the script back across repos at any point in time.
I'll merge this on Monday or Tuesday, in case Jukka wants to do a 0.972 (in which case I'd like to avoid build changes right before he does so)

[ben9923]

@hauntsaninja Thanks for reviewing :)

I have a different suggestion - Maybe wheels build workflow should move entirely to this project?
It makes a little more sense to me to have it here, as those wheels are the ones eventually uploaded to PyPI (right?).

Coupling the CI configuration with the project's repo should make it easier to review and adapt to changes.
Having cibuildwheel configuration as part of pyproject.toml (desired end state?) is a good example for this method's advantages.

Problem with that approach is that only 'regular' releases will have an actual GitHub release, but is it really that bad to get development wheels from workflow's build artifacts?

Anyway as you said, it's something to address later 😛

[ben9923]

@hauntsaninja Is it still going to be merged soon? 😉 (Edit: Saw the label now haha)

Rebased it to fix conflicts and ran black on it, though I must say some of those code style changes are questionable (to me anyway)... It looks weird.

This change for example in build_wheel.py. It makes code less readable IMO, why all those newlines are needed?

-    env['CIBW_BEFORE_TEST'] = """
+    env[
+        "CIBW_BEFORE_TEST"
+    ] = """
       (
       grep -v lxml {project}/mypy/test-requirements.txt > /tmp/test-requirements.txt
       && cp {project}/mypy/mypy-requirements.txt /tmp/mypy-requirements.txt
       && cp {project}/mypy/build-requirements.txt /tmp/build-requirements.txt
       && pip install -r /tmp/test-requirements.txt
       )
-    """.replace('\n', ' ')
+    """.replace(
+        "\n", " "
+    )

Note there are some new failures when invoking build workflow for Python 3.6, 3.10 and sdist jobs.
Python 3.6 should be removed from CI, code style hook & config should be excluded by MANIFEST, no idea what broke 3.10.

[hauntsaninja]

Thanks for rebasing.

Agreed that some of black's decisions here are questionable. But.... whatever 🤷

Thanks for mentioning. check-manifest should be fixed by #13288
Best guess for Python 3.10 is that there's a difference in error reporting between Python 3.10.0 and Python 3.10.5; I'll look into fixing it

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[hauntsaninja]

Okay, hopefully:
#13289
and
mypyc/mypy_mypyc-wheels#42
gets wheel builds green again

[ben9923]

Seems like it does, thanks for the effort :)

[hauntsaninja]

Great, merged both your PRs, thank you for this!