Co-authored-by: hauntsaninja <>

For context, I've been testing whether a range of popular libraries are going to work on Windows ARM64. (This requires compiling on a regular x64 machine and then copying the wheel to an ARM64 one for testing.)

The good news is, coverage seems to be just fine without any changes. However, because of a few assumptions in the test suite about always testing an in-place build, I had to make some tweaks to be able to run tests. My proposed tweaks should be fine for current uses, but they also allow the following:

* support `SETUPTOOLS_EXT_SUFFIX` when building to override the pyd tag on Windows (used with `setup.py build_ext -L <path>` to point at [pythonarm64](https://www.nuget.org/packages/pythonarm64/) import libraries to do the cross-compile)
* allow `COVERAGE_INSTALL_ARGS` to override how the tests install coverage into a venv (allows to point at a wheel rather than rebuilding from the sources)
* allow `python igor.py remove_extension --from-install` to delete the extension module from `site-packages` rather than only the source tree
* other changes to allow removing the `coverage` directory from the source tree before tests so that the installed copy will be used instead.

I've tested these on my own Windows ARM64 machine, though unfortunately there aren't any available on CI services yet. If you wanted to start releasing (preview) wheels for win-arm64 you can, but there's no support (yet) in `cibuildwheel` or `build` to do it (because those tools don't really have a concept of cross-compilation for Windows at all... yet ;-) ).

For the linter

[skip actions]

The fix for CTracer is egregious and will need to be updated when there's a
supported way to do it.

The fullcoverage skip is noted in
https://github.com/nedbat/coveragepy/issues/1278

The raise_through_with skip is noted in
https://github.com/nedbat/coveragepy/issues/1270

.. and also add trailing commas where needed to remove ambiguity.

I used semgrep with this config:
```
rules:
  - id: implicit-string-concatenation
    pattern: |
      "$X" "$Y"
    languages:
      - python
    message: string cat BAD
    severity: INFO
```

Running it showed this:

```
$ semgrep --config=../lab/string-cat.yml coverage tests doc ci igor.py setup.py __main__.py
Running 1 rules...
setup.py
severity:info rule:lab.implicit-string-concatenation: string cat BAD
128:            'https://tidelift.com/subscription/pkg/pypi-coverage'
129:            '?utm_source=pypi-coverage&utm_medium=referral&utm_campaign=pypi'

tests/test_api.py
severity:info rule:lab.implicit-string-concatenation: string cat BAD
319:            "!coverage.py: This is a private format, don't read it directly!"
320:            '{"lines":{"/private/tmp/foo.py":[1,5,2,3]}}'

tests/test_html.py
severity:info rule:lab.implicit-string-concatenation: string cat BAD
614:            ('<span class="key">if</span> <span class="num">1</span> '
615:             '<span class="op">&lt;</span> <span class="num">2</span>'),
--------------------------------------------------------------------------------
616:            ('    <span class="nam">a</span> '
617:             '<span class="op">=</span> <span class="num">3</span>'),
--------------------------------------------------------------------------------
665:            ('<span class="key">if</span> <span class="nam">x</span> '
666:             '<span class="op">&lt;</span> <span class="num">2</span>'),
--------------------------------------------------------------------------------
667:            ('    <span class="nam">a</span> <span class="op">=</span> '
668:             '<span class="num">3</span>'),
--------------------------------------------------------------------------------
949:            ('<span class="key">if</span> <span class="num">1</span> '
950:             '<span class="op">&lt;</span> <span class="num">2</span>'),
--------------------------------------------------------------------------------
951:            ('    <span class="nam">a</span> <span class="op">=</span> '
952:             '<span class="num">3</span>'),
ran 1 rules on 134 files: 8 findings
```

This wasn't all of the instances, so I wrote a bug report: https://github.com/returntocorp/semgrep/issues/4184

This makes exceptions report their causes correctly, as "The above exception was
the direct cause of the following exception" instead of "During handling of the
above exception, another exception occurred."