This is another problem caused by
#19398 and a missing part of
#20254 cc @JukkaL

@hauntsaninja there is a small chance this may be related to the
problems with black.

Fixes an issue where a subclass would have its vtable pointer set to the
base class' vtable when there is a `__new__` method defined in the base
class. This resulted in the subclass constructor calling the setup
function of the base class because mypyc transforms `object.__new__`
into the setup function.

The fix is to store the pointers to the setup functions in `tp_methods`
of type objects and look them up dynamically when instantiating new
objects.

---------

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

…uild flags (#20253)

Fixes the current SSE4.2 requirement added in
1b6ebb1
/ #20244

This PR fully enables the existing x86-64 CPU detection and dispatch
code for SSSE3, SSE4.1, SSE4.2, AVX, and AVX2 in the base64 module.

To use the existing CPU dispatch from the [upstream base64
code](https://github.com/aklomp/base64), one needs to compile the
sources in each of the CPU specific codec directories with a specific
compiler flag; alas this is difficult to do with setuptools, but I found
a solution inspired by https://stackoverflow.com/a/68508804

Note that I did not enable the AVX512 path with this PR, as many intel
CPUs that support AVX512 can come with a performance hit if AVX512 is
sporadically used; the performance of the AVX512 (encoding) path need to
be evaluated in the context of how mypyc uses base64 in various
realistic scenarios. (There is no AVX512 accelerated decoding path in
the upstream base64 codebase, it falls back to the avx2 decoder).

If there are additional performance concerns, then I suggest
benchmarking with the openmp feature of base64 turned on, for multi-core
processing.

Added a draft version with the commits filtered to remove internal
changes and grouped into sections.

---------

Co-authored-by: Jacopo Abramo <jacopo.abramo@gmail.com>

The first draft was added in #20296.

Fixes #20326

Type variables with forward references in upper bound are known to be
problematic. Existing mechanisms to work with them implicitly assumed
that they are used in the same module where they are defined, which is
not necessarily the case for "old-style" type variables that can be
imported.

Note that the simplification I made in `semanal_typeargs.py` would be
probably sufficient to fix this, but that would be papering over the
real issue, so I am making a bit more principled fix.

Fixes #20327

Fix is trivial, do not grab various internal/temporary symbols with star
imports. This may create an invalid cross-reference (and is generally
dangerous). Likely, this worked previously because we processed all
fresh modules in queue, not just the dependencies of current SCC.

Fixes #20093

This fixes the crash, but not the false positive (the false positive
existed prior to the regression that introduced the crash)

Fixes #20344

This PR fixes #20341

Fixes #20367

Fixes mypyc/librt#21

Fail with an explicit user-friendly error on PyPy.

Follow-up for #20384

Fixes #20353

This makes us respect e.g. `--output json` for cached files without
re-checking the files (which is the desired behavior for users, see
issue). This is also a first step towards resolving the "foo defined
here" conundrum for parallel checking.

The fix is straightforward. The only question was whether to continue
using `ErrorTuple`s or switch to a proper class. I decided to keep the
tuples for now to minimize the scope of change.

Note I am also adjusting generic "JSON" fixed-format helpers to natively
support tuples (unlike real JSON). We already use tuples in few other
places, so it makes sense to just make it "official" (this format is
still internal to mypy obviously).

Also change the header for 1.18 because of
#19910