Describe the bug A clear and concise description of the bug.

We've been having issues with our CI in GitHub Actions for the last few hours, and think it might be because of Coverage 6.3 - it's the one thing that's changed, and freezing it at 6.2 seems to allow runs to complete successfully.

To Reproduce How can we reproduce the problem? Please be specific. Don't link to a failing CI job. Answer the questions below:

1. What version of Python are you using? 3.7 seems to be a bit buggy with this. We also run 3.8 - 3.10 in CI and no issues seen with that.
2. What version of coverage.py shows the problem? The output of coverage debug sys is helpful. 6.2.3
3. What versions of what packages do you have installed? The output of pip freeze is helpful. See https://gist.github.com/tunetheweb/4d288ea4467ba74a66b3a0e2e8d5e4ea
4. What code shows the problem? Give us a specific commit of a specific repo that we can check out. If you've already worked around the problem, please provide a commit before that fix. This is tricky. We run a lot of commands in CI, but checking out https://github.com/sqlfluff/sqlfluff/ and running tox -e py37 -- -n 2 test should reproduce it. Having problems setting up a 3.7 environment but will try to get a better test case. We do use a multithreaded process and noticed some changes to that.
5. What commands did you run?

Expected behavior A clear and concise description of what you expected to happen.

Additional context Add any other context about the problem here.

Will try to get a better repo.

Describe the bug Since coverage v5.0.2, I throw an exception during Python 3.6 testing (Python 3.4, 3.5, 3.7, and 3.8 work fine - source). Below is a screenshot of the exception thrown (source)

This problem does not occur with v5.0.1 (source).

Originally I thought this was a Travis CI issue (source), but it appears specific to the last release of coverage instead.

To Reproduce How can we reproduce the problem? Please be specific.

1. Python v3.6.7
2. Ubuntu 16.04.6 LTS
3. Kernel: 4.15.0-1028-gcp (xenial container here)
4. v5.0.2 of coverage (pulled from PyPi/pip)
5. The following packages are installed:

   apprise==0.8.2
   asgiref==3.2.3
   attrs==19.3.0
   certifi==2019.11.28
   chardet==3.0.4
   Click==7.0
   coverage==5.0.2
   Django==3.0.2
   entrypoints==0.3
   filelock==3.0.12
   flake8==3.7.9
   idna==2.8
   importlib-metadata==1.3.0
   Markdown==3.1.1
   mccabe==0.6.1
   mock==3.0.5
   more-itertools==8.0.2
   oauthlib==3.1.0
   packaging==20.0
   pluggy==0.13.1
   py==1.8.1
   pycodestyle==2.5.0
   pyflakes==2.1.1
   pyparsing==2.4.6
   pytest==5.3.2
   pytest-cov==2.8.1
   pytest-django==3.7.0
   pytz==2019.3
   PyYAML==5.3
   requests==2.22.0
   requests-oauthlib==1.3.0
   six==1.13.0
   sqlparse==0.3.0
   toml==0.10.0
   tox==3.14.3
   urllib3==1.25.7
   virtualenv==16.7.9
   wcwidth==0.1.8
   zipp==0.6.0
   

6. I'm trying to build my package Apprise API which I hadn't needed to build until of late. Here is the latest build status.
7. The command ran was:

   coverage run --parallel -m pytest apprise_api
   

Expected behavior Not to get an exception (or maybe it just needs to be gracefully caught since it's on an __exit__ call anyway)?

Additional context If i re-run the Travis-CI runner on a previous Python 3.6 test runner that has passed (in the past), it fails on Python 3.6 (more details and screenshots explained here).

Originally reported by andrea crotti (Bitbucket: andrea_crotti, GitHub: Unknown)

I was just using the awesome HTML report to see my test coverage and I had the following thought.

Wouldn't it be nice to be able to see easily what parts of the test suites are actually testing my code?

I guess that these information is collected while doing the annotation, right?

In this way we could actually see if the tests are actually good very easily, which is specially important when working with other people code.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/170

Originally reported by k3it (Bitbucket: k3it, GitHub: k3it)

I apologize for a cross post from http://stackoverflow.com/q/43991865/1653558 but it looks like this is a better place for the report

I'm getting some low coverage numbers on script with threads activated with a run() method. It seems that the coverage module is unable to keep track of all hits. Here is the code that demonstrates the problem. Running it should produce 100% coverage, but I'm getting 71.

#!python

from threading import Thread

class MyNestedThread(Thread):
        def run(self):
                print("hello from the nested thread!")

class MyThread(Thread):
        def run(self):
                print("Hello from thread")
                t = MyNestedThread()
                t.start()
                return

if __name__ == '__main__':
        for i in range(3):
                t = MyThread()
                t.start()

#!python


Hello from thread
hello from the nested thread!
Hello from thread
Hello from thread
hello from the nested thread!
hello from the nested thread!

Name     Stmts   Miss  Cover
----------------------------
foo.py      14      4    71%

re-running 'coverage run foo.py' sometimes gives a different %, and even 100% on occasion.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/582

Originally reported by Samuel Colvin (Bitbucket: samuelcolvin, GitHub: samuelcolvin)

I'm getting CoverageException: Can't combine line data with arc dat when using coverage with the pytest-cov pytest extension. I think this is similar to #399, but that issue is closed.

Example failure on travis: https://travis-ci.org/samuelcolvin/arq/builds/148541711

The test causing problems is using click's CliRunner, code here. The CLI command that's testing starts another process (using multiprocessing.Process) to run the worker which is what's causing the problem, if you prevent the worker process being started the exception doesn't occur.

I tried changing the concurrency mode but it made no difference.

To reproduce: clone, pip install -e . && pip install -r tests/requirements.txt, py.test --cov=arq.

relevant bits of pip freeze:

click==6.6
coverage==4.2
pytest==2.9.2
pytest-cov==2.3.0

Let me know if you need anymore information.

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/512

The below issue is with Coverage version 5.0a7

When trying to run test for my django project using coverage run manage.py test i get ModuleNotFoundError. This issue kept coming and i thought it was as a result of what was addressed here --> https://stackoverflow.com/questions/50378166/django-coverage-modulenotfounderror-no-module-named-django-extensions

None of the recommendations worked, i downgraded my django version from 3.0 to 2.2 and the problem persisted. This issue was rectified by downgrading to coverage version 4.5

Like i said, i only encountered this issue with coverage version 5.0a7

With the below dependencies, coverage is working as expected

λ pipenv run pip list
Package          Version
---------------- -------
asgiref              3.2.3
coverage          4.5
Django              2.2
Pillow               6.2.1
pip                   19.3.1
psycopg2         2.8.4
pytz                2019.3
setuptools       41.4.0
sqlparse         0.3.0
wheel            0.33.6

complete error log

Traceback (most recent call last):
  File "manage.py", line 21, in <module>
    main()
  File "manage.py", line 17, in main
    execute_from_command_line(sys.argv)
  File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\core\management\__init__.py", line 401, in execute_from_command_line
    utility.execute()
  File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\core\management\__init__.py", line 395, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\core\management\commands\test.py", line 23, in run_from_argv
    super().run_from_argv(argv)
  File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\core\management\base.py", line 320, in run_from_argv
    parser = self.create_parser(argv[0], argv[1])
  File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\core\management\base.py", line 294, in create_parser
    self.add_arguments(parser)
  File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\core\management\commands\test.py", line 44, in add_arguments
    test_runner_class = get_runner(settings, self.test_runner)
  File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\test\utils.py", line 301, in get_runner
    test_runner_class = test_runner_class or settings.TEST_RUNNER
  File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\conf\__init__.py", line 76, in __getattr__
    self._setup(name)
  File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\conf\__init__.py", line 63, in _setup
    self._wrapped = Settings(settings_module)
  File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\site-packages\django\conf\__init__.py", line 142, in __init__
    mod = importlib.import_module(self.SETTINGS_MODULE)
  File "c:\users\spaceofmiah\.virtualenvs\backend--o8je5ax\lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 978, in _gcd_import
  File "<frozen importlib._bootstrap>", line 961, in _find_and_load
  File "<frozen importlib._bootstrap>", line 936, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 205, in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 978, in _gcd_import
  File "<frozen importlib._bootstrap>", line 961, in _find_and_load
  File "<frozen importlib._bootstrap>", line 936, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 205, in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 978, in _gcd_import
  File "<frozen importlib._bootstrap>", line 961, in _find_and_load
  File "<frozen importlib._bootstrap>", line 948, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'newproject'

Originally reported by Anonymous

I do not have a minimum repro for this issue yet, but we're seeing errors in our CI after upgrading coverage from 4.3.4 to 4.4b1 and 4.4.

We have some tests running using rostest. Upon upgrading from coverage 4.3.4 on our CI server, we started seeing the following errors:

Traceback (most recent call last):
  File "/tmp/tmpw8DgrF/src/app/test/integration/test_head_service.py", line 86, in <module>
    main()
  File "/tmp/tmpw8DgrF/src/app/test/integration/test_head_service.py", line 82, in main
    rostest.rosrun(PKG, NAME, TestHeadService)
  File "/opt/ros/indigo/lib/python2.7/dist-packages/rostest/__init__.py", line 148, in rosrun
    _stop_coverage([package])
  File "/opt/ros/indigo/lib/python2.7/dist-packages/rostest/__init__.py", line 227, in _stop_coverage
    _cov.stop()
  File "/usr/local/lib/python2.7/dist-packages/coverage/control.py", line 899, in analysis
    f, s, _, m, mf = self.analysis2(morf)
  File "/usr/local/lib/python2.7/dist-packages/coverage/control.py", line 920, in analysis2
    analysis = self._analyze(morf)
  File "/usr/local/lib/python2.7/dist-packages/coverage/control.py", line 935, in _analyze
    self.get_data()
  File "/usr/local/lib/python2.7/dist-packages/coverage/control.py", line 824, in get_data
    if self.collector.save_data(self.data):
  File "/usr/local/lib/python2.7/dist-packages/coverage/collector.py", line 382, in save_data
    covdata.add_lines(abs_file_dict(self.data))
  File "/usr/local/lib/python2.7/dist-packages/coverage/collector.py", line 377, in abs_file_dict
    return dict((abs_file(k), v) for k, v in iitems(d))
  File "/usr/local/lib/python2.7/dist-packages/coverage/collector.py", line 377, in <genexpr>
    return dict((abs_file(k), v) for k, v in iitems(d))

It's possible this is a rostest issue too - I haven't dug down very deeply, but we're certain that this issue does not occur when using coverage 4.3.4 - only 4.4b1 and 4.4.

The source code for the caller is found here. It looks like stop is being called from line 227 and then blowing up internally.

Will post more info once I have it.

Contact info: [email protected]

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/581
• This issue had attachments: repro.py. See the original issue for details.

Missing docstrings and tests at the moment. If this looks like the right idea I can start adding those.

Example pyproject.toml:

[tool.coverage.run]
branch = true
source = ["outcome", "tests/"]

[tool.coverage.report]
precision = 1
exclude_lines = [
    "pragma: no cover",
    "abc.abstractmethod",
]

Resolves #664

Current Problem I'm running coverage for multiple Python versions on both Linux and Windows. They are all run on Gitlab, with the Windows tests using Python install on the host, and with the Linux tests using Docker. The paths of the build directories are not deterministic (may be picked up by multiple runners, existing or yet to exist) so I have relative_files = True .

The Windows paths use \ instead of / which, if the coverage combination and reporting is done on Windows, results in a report with every source file twice, one for each separator, although the end result appears to be correct. If this is done on Linux, it fails entirely when trying to resolve the paths containing backslashes.

Example Report

Name                                           Stmts   Miss Branch BrPart  Cover
 --------------------------------------------------------------------------------
 exmpl\__about__.py                                 6      0      0      0   100%
 exmpl/__about__.py                                 6      0      0      0   100%
 exmpl/__init__.py                                298     11    138      5    95%
 exmpl\__init__.py                                298     11    138      5    95%
 exmpl/_logging.py                                 47      2     16      1    92%
 exmpl\_logging.py                                 47      2     16      1    92%
 exmpl/cli.py                                      55      0     28      0   100%
 exmpl\cli.py                                      55      0     28      0   100%
etc...

Describe the solution you'd like Source paths on Windows should use forward slashes in relative paths to allow result combination and final reporting to be done on Linux, and to clean up the report output when done on Windows.

Describe alternatives you've considered Manually modifying the coverage results generated from coverage run.

Originally reported by Matthew Crenshaw (Bitbucket: sgtsquiggs, GitHub: sgtsquiggs)

So that we can use coverage.py with IDE plugins that read the standard lcov.info format and highlight covered/uncovered lines. Would be super great!

• Bitbucket: https://bitbucket.org/ned/coveragepy/issue/587

I posted a question on Stackoverflow because the time for my tests running with coverage and Python 3.7 were about 8 times longer than with Python 3.5 and 3.6. Hoefling suggested I run the tests without coverage and times for testing were about the same for the different versions. Hoefling suggested that it might be a coverage regression and that I post an issue.

Repro https://github.com/platformdirs/platformdirs/tree/aa671aaa97913c7b948567f4d9c77d4f98bfa134 Failing example https://github.com/platformdirs/platformdirs/actions/runs/3827864380/jobs/6512833737

---------- coverage: platform linux, python 3.11.1-final-0 -----------
Name                                                                                                            Stmts   Miss Branch BrPart  Cover   Missing
-----------------------------------------------------------------------------------------------------------------------------------------------------------
//home/runner/work/platformdirs/platformdirs/.tox/py311/lib/python3.11/site-packages/platformdirs/__init__.py      60     60     10      0     0%   5-318
//home/runner/work/platformdirs/platformdirs/.tox/py311/lib/python3.11/site-packages/platformdirs/android.py       66     66     30      0     0%   1-118
//home/runner/work/platformdirs/platformdirs/.tox/py311/lib/python3.11/site-packages/platformdirs/api.py           79     79     76      0     0%   1-156
//home/runner/work/platformdirs/platformdirs/.tox/py311/lib/python3.11/site-packages/platformdirs/unix.py          96     96     56      0     1%   1-179
//home/runner/work/platformdirs/platformdirs/.tox/py311/lib/python3.11/site-packages/platformdirs/version.py        2      2      0      0     0%   3-4
src/platformdirs/__init__.py                                                                                       60      2     10      2    94%   23, 25
src/platformdirs/android.py                                                                                        66     23     30      0    72%   22, 27, 34, [39](https://github.com/platformdirs/platformdirs/actions/runs/3827864380/jobs/6512833737#step:8:40), [44](https://github.com/platformdirs/platformdirs/actions/runs/3827864380/jobs/6512833737#step:8:45), 49, 57-60, 67, 75-78, 106-115
src/platformdirs/api.py                                                                                            79      2     76      0    99%   121, 131
src/platformdirs/macos.py                                                                                          32     32     18      0     0%   1-62
src/platformdirs/unix.py                                                                                           96      9     56      2    90%   154, 162-174
src/platformdirs/windows.py                                                                                        96     96     [45](https://github.com/platformdirs/platformdirs/actions/runs/3827864380/jobs/6512833737#step:8:46)      0     0%   1-182
-----------------------------------------------------------------------------------------------------------------------------------------------------------
TOTAL                                                                                                             963    [46](https://github.com/platformdirs/platformdirs/actions/runs/3827864380/jobs/6512833737#step:8:47)7    [47](https://github.com/platformdirs/platformdirs/actions/runs/3827864380/jobs/6512833737#step:8:48)7      4    51%

It must be related to path mapping.

Still working example with earlier version https://github.com/platformdirs/platformdirs/actions/runs/3821177309/jobs/6500063137. I've fixed the main branch for now by moving to relative files https://github.com/platformdirs/platformdirs/commit/72f09fa1252651f20a1ed4ea0b2bbdc310d59dba

Describe the bug

Twine's scheduled CI failed this morning, because the coverage percentage dropped below the threshold under Python 3.7 (GHA), with 1785 statements executed. The day before, it passed (GHA), with 1807 statements executed. There were no commits in between. The only difference that I'm aware of is the release of Coverage.py 7.0.2, but I don't see any red flags in the release notes.

To Reproduce

1. What version of Python are you using?

   3.7 and 3.8

2. What version of coverage.py shows the problem? The output of coverage debug sys is helpful.

   7.0.2

3. What versions of what packages do you have installed? The output of pip freeze is helpful.

   % .tox/py37/bin/pip freeze

    attrs==22.2.0
    bleach==5.0.1
    build==0.9.0
    certifi==2022.12.7
    charset-normalizer==2.1.1
    commonmark==0.9.1
    coverage==7.0.2
    docutils==0.19
    exceptiongroup==1.1.0
    idna==3.4
    importlib-metadata==6.0.0
    importlib-resources==5.10.2
    iniconfig==1.1.1
    jaraco.classes==3.2.3
    keyring==23.13.1
    more-itertools==9.0.0
    packaging==22.0
    pep517==0.13.0
    pkginfo==1.9.2
    pluggy==1.0.0
    pretend==1.0.9
    Pygments==2.14.0
    pytest==7.2.0
    pytest-socket==0.5.1
    readme-renderer==37.3
    requests==2.28.1
    requests-toolbelt==0.10.1
    rfc3986==2.0.0
    rich==13.0.0
    six==1.16.0
    tomli==2.0.1
    twine @ file:///Users/bhrutledge/Dev/twine/.tox/.tmp/package/35/twine-4.0.3.dev21%2Bg89fba32.d20230103.tar.gz
    typing_extensions==4.4.0
    urllib3==1.26.13
    webencodings==0.5.1
    zipp==3.11.0
   

4. What code shows the problem?

   https://github.com/pypa/twine/tree/89fba32c3cf56ff6b02c691154b3de7faf7def04

5. What commands did you run?

   I'm able to reproduce this locally by running tox -e py37 and changing the coverage requirement in deps (e.g. to coverage==7.0.1 and coverage<7).

Expected behavior

The number of executed statements should be the same as previous versions.

Additional context

There's no change in statements from Coverage.py 6.5.0 to 7.0.1; both report 1807.

Also maybe worth noting that py37 has always seemed to be lower; py38 and greater seem to consistently execute 1856 statements, with no change across Coverage.py versions.

Currently, coverage xml/html report prints the path of the file written to stdout:

py311: commands[4]> coverage xml -o /home/bernat/git/virtualenv/.tox/coverage.py311.xml
Wrote XML report to /home/bernat/git/virtualenv/.tox/coverage.py311.xml
py311: commands[5]> coverage html -d /home/bernat/git/virtualenv/.tox/py311/tmp/htmlcov --show-contexts --title virtualenv-py311-coverage
Wrote HTML report to /home/bernat/git/virtualenv/.tox/py311/tmp/htmlcov/index.html

It would be great if we'd prepend the file:/ protocol prefix to this path so these links are clickable from the modern terminal, like iTerm or wezterm. I'm ok if it requires a flag to enable this behavior, as I can add that flag to tox.

See:

• https://wezfurlong.org/wezterm/hyperlinks.html#implicit-hyperlinks
• https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda

The file prefix enables integrated hyperlinks in all modern terminals.

Perhaps a better and more complicated alternative would be to hide it behind an extra and use rich to print integrated hyperlinks - see https://www.willmcgugan.com/blog/tech/post/real-working-hyperlinks-in-the-terminal-with-rich whenever tty is detected; this would allow to avoid the file prefix and also enable it for coverage report.

If you consider this feature out of scope for the core project, I'd request some way to achieve this via a plugin :blush:

When doing https://github.com/pypa/virtualenv/pull/2477 I noticed that with relative_files report.omit seems no longer active. See failing run https://github.com/pypa/virtualenv/actions/runs/3824948711/jobs/6507540653, while before turning relative files on here https://github.com/pypa/virtualenv/actions/runs/3821105582/jobs/6499921063 seems to still work.

The config file is here: https://github.com/gaborbernat/virtualenv/blob/fix/pyproject.toml#L96-L112

Describe the bug In my flask project, running through pytest with the pytest-flask plugin, a subprocess gets started. I get two .coverage..* files that get generated, but the report shows lines as missing. If I run the same tests on a debugger and set a breakpoint there, those lines are hit... but still report missing.

UPDATE: There is one of the methods on a specific file in which a single line is reported missing (out of 5). I have checked the plugin starting the subprocess, (pytest-flask, file live_server.py) and it sends a SIGINT to the process before calling the join (which seems to be aligned with coverage recommendations).

To Reproduce How can we reproduce the problem? Please be specific. Don't link to a failing CI job. Answer the questions below:

1. What version of Python are you using? 3.10.8
2. What version of coverage.py shows the problem?

-- sys -------------------------------------------------------
               coverage_version: 7.0.1
                coverage_module: ~/venv/lib/python3.10/site-packages/coverage/__init__.py
                         tracer: -none-
                        CTracer: available
           plugins.file_tracers: -none-
            plugins.configurers: -none-
      plugins.context_switchers: -none-
              configs_attempted: .coveragerc
                   configs_read: ~/.coveragerc
                    config_file: ~/.coveragerc
                config_contents: b"[run]\nbranch = true\nparallel = true\nconcurrency = multiprocessing\nsigterm = true\nomit =\n    backend/tests/*\n    backend/blueprints/test.py\n    backend/blueprints/checkout.py\n\n[report]\nfail_under = 90\nshow_missing = True\n\n# Regexes for lines to exclude from consideration\nexclude_lines =\n    # Have to re-enable the standard pragma\n    pragma: no cover\n\n    # Don't complain about missing debug-only code:\n    def __repr__\n    if self\\.debug\n\n    # Don't complain if non-runnable code isn't run:\n    if 0:\n    if __name__ == .__main__.:\n\n    # Don't complain about abstract methods, they aren't run:\n    @(abc\\.)?abstractmethod\n"
                      data_file: -none-
                         python: 3.10.8 (main, Nov  1 2022, 14:18:21) [GCC 12.2.0]
                       platform: Linux-6.0.12-arch1-1-x86_64-with-glibc2.36
                 implementation: CPython
                     executable: ~/venv/bin/python
                   def_encoding: utf-8
                    fs_encoding: utf-8
                            pid: 154712
                            cwd: ~
                           path: ~/venv/bin
                                 /usr/lib/python310.zip
                                 /usr/lib/python3.10
                                 /usr/lib/python3.10/lib-dynload
                                 ~/venv/lib/python3.10/site-packages
                    environment: HOME = ~
                   command_line: ~/venv/bin/coverage debug sys
                sqlite3_version: 2.6.0
         sqlite3_sqlite_version: 3.40.0
             sqlite3_temp_store: 0
        sqlite3_compile_options: ATOMIC_INTRINSICS=1, COMPILER=gcc-12.2.0, DEFAULT_AUTOVACUUM,
                                 DEFAULT_CACHE_SIZE=-2000, DEFAULT_FILE_FORMAT=4,
                                 DEFAULT_JOURNAL_SIZE_LIMIT=-1, DEFAULT_MMAP_SIZE=0, DEFAULT_PAGE_SIZE=4096,
                                 DEFAULT_PCACHE_INITSZ=20, DEFAULT_RECURSIVE_TRIGGERS,
                                 DEFAULT_SECTOR_SIZE=4096, DEFAULT_SYNCHRONOUS=2,
                                 DEFAULT_WAL_AUTOCHECKPOINT=1000, DEFAULT_WAL_SYNCHRONOUS=2,
                                 DEFAULT_WORKER_THREADS=0, ENABLE_COLUMN_METADATA, ENABLE_DBSTAT_VTAB,
                                 ENABLE_FTS3, ENABLE_FTS3_PARENTHESIS, ENABLE_FTS3_TOKENIZER, ENABLE_FTS4,
                                 ENABLE_FTS5, ENABLE_MATH_FUNCTIONS, ENABLE_RTREE, ENABLE_STMTVTAB,
                                 ENABLE_UNLOCK_NOTIFY, HAVE_ISNAN, MALLOC_SOFT_LIMIT=1024, MAX_ATTACHED=10,
                                 MAX_COLUMN=2000, MAX_COMPOUND_SELECT=500, MAX_DEFAULT_PAGE_SIZE=8192,
                                 MAX_EXPR_DEPTH=10000, MAX_FUNCTION_ARG=127, MAX_LENGTH=1000000000,
                                 MAX_LIKE_PATTERN_LENGTH=50000, MAX_MMAP_SIZE=0x7fff0000,
                                 MAX_PAGE_COUNT=1073741823, MAX_PAGE_SIZE=65536, MAX_SQL_LENGTH=1000000000,
                                 MAX_TRIGGER_DEPTH=1000, MAX_VARIABLE_NUMBER=250000, MAX_VDBE_OP=250000000,
                                 MAX_WORKER_THREADS=8, MUTEX_PTHREADS, SECURE_DELETE, SYSTEM_MALLOC,
                                 TEMP_STORE=1, THREADSAFE=1

3. What versions of what packages do you have installed?

attrs==22.2.0
certifi==2022.12.7
charset-normalizer==2.1.1
click==8.1.3
exceptiongroup==1.1.0
Flask==2.2.2
Flask-Cors==3.0.10
Flask-Login==0.6.2
Flask-SQLAlchemy==3.0.2
Flask-WTF==1.0.1
greenlet==2.0.1
gunicorn==20.1.0
idna==3.4
iniconfig==1.1.1
itsdangerous==2.1.2
Jinja2==3.1.2
MarkupSafe==2.1.1
numpy==1.24.1
packaging==22.0
pluggy==1.0.0
psycopg2==2.9.5
pydot==1.4.2
pyparsing==3.0.9
pytest==7.2.0
pytest-flask==1.2.0
python-dotenv==0.21.0
PyYAML==6.0
requests==2.28.1
six==1.16.0
SQLAlchemy==1.4.45
SQLAlchemy-Utils==0.39.0
stripe==5.0.0
tomli==2.0.1
urllib3==1.26.13
Werkzeug==2.2.2
WTForms==3.0.1

4. What code shows the problem? It is a private repo, I cannot share :-/
5. What commands did you run?

rm -f .coverage.*
coverage run -m pytest
coverage combine
coverage report 

Expected behavior I get the information related to the coverage of the statements run by the subprocess that is running the flask server.

Describe the bug When setting the branch flag to true in run options via a pyproject.toml, an error occurs when parsing the toml file if the boolean value casing is "True".

Python Version: 3.11 in a Poetry venv Coverage.py Version: 7.0.1

To Reproduce

Create a pyproject.toml file with the following configuration option:

[tool.coverage.run]
branch = "True"

Console Output:

(dashboard-py3.11) PS C:\Users\**********\repos\dashboard> coverage run -m pytest   
Couldn't read config file pyproject.toml: Option [tool.coverage.run]branch couldn't convert to a boolean: 'True'

My full pyproject.toml:

[tool.poetry]
name = "dashboard"
version = "0.1.0"
description = ""
authors = [<OMITTED>]
readme = "README.md"

[tool.poetry.dependencies]
python = "^3.11"
flask = "^2.2.2"
flask-login = "^0.6.2"
requests = "^2.28.1"
pytest = "^7.2.0"
python-dotenv = "^0.21.0"
coverage = "^7.0.1"
black = {extras = ["d"], version = "^22.12.0"}
flask-sqlalchemy = "^3.0.2"
flask-dance = {extras = ["sqla"], version = "^6.2.0"}
blinker = "^1.5"
pytest-flask-sqlalchemy = "^1.1.0"

[tool.pytest.ini_options]
testpaths = ["tests"]

[tool.coverage.run]
branch = "true"
source = ["app"]


[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

Expected behavior The configuration documentation states: "Coverage.py will read from pyproject.toml if TOML support is available . . . Environment variable expansion in values is available, but only within quoted strings, even for non-string values. " This indicates that Boolean values should be enclosed within quotes as a string since the TOML standard does not support native Boolean Types.

In the documentation section below this pyproject.toml compatibility note titled "Syntax", it states: "Boolean values can be specified as on, off, true, false, 1, or 0 and are case-insensitive."

Following these examples of using an all lowercase "true" does solve the problem and coverage will run perfectly fine; however, the documentation does indicate that it is case-insensitive and considering that the Python bool value True doesn't work, it may be counterintuitive at first to write true in this way.

It is not so much a bug that prevents coverage from running but moreso a difference in the documentation that creates confusion. I do not know if this TOML case-sensitive parsing behavior is intended and the documentation fails to mention this pyproject.toml specific case, or if the parsing needs to be adjusted to match the current documentation of being case-insensitive.