Coverage does not work for packages that use internal libraries or library components #6440

newhoggy · 2019-12-16T23:38:49Z

Describe the bug
Coverage does not work for packages that use internal libraries or library components. This is true even if package is only a build dependency, making it very easy encounter this issue on any reasonably sized project.

To Reproduce
Steps to reproduce the behavior:

$ git clone git@github.com:haskell-works/hw-ip.git
$ cd hw-ip
$ cabal v2-test --enable-coverage
Error:
    Internal libraries only supported with per-component builds.
    Per-component builds were disabled because program coverage is enabled
    In the package 'hw-ip-2.4.0.1'

Please use version-prefixed commands (e.g. v2-build or v1-build) to avoid ambiguity.

Expected behavior
I expect coverage to just work for any typical package that has been published to hackage.

System information

$ cabal --version
cabal-install version 3.0.0.0
compiled using version 3.0.0.0 of the Cabal library
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.6.5
$ uname -a
Darwin INTLKyMac.local 18.7.0 Darwin Kernel Version 18.7.0: Sat Oct 12 00:02:19 PDT 2019; root:xnu-4903.278.12~1/RELEASE_X86_64 x86_64

Additional context
None

The text was updated successfully, but these errors were encountered:

symbiont-sam-halliday · 2020-03-23T18:42:51Z

I also observe this with cabal-install 3.0.0.0 and ghc-8.3.3.

It is unfortunate, because the equivalent command works in stack on the same project.

If I do --enable-coverage --disable-library-coverage I don't see any files after running cabal test.

symbiont-sam-halliday · 2020-03-26T12:43:30Z

Workaround: #5213 (comment)

tl;dr specifically disable coverage for libraries that use internal libraries, e.g.

package *
  coverage: True
  library-coverage: True

package dns
  coverage: False
  library-coverage: False

(note that this doesn't work if we don't use package *)

ivanperez-keera · 2022-05-07T23:18:00Z

I believe this may be the reason behind copilot-core's tests being reported as broken on hackage.

I ran the build in a docker image using:

cabal test all --enable-coverage --disable-optimization copilot**/

and was met with:

Resolving dependencies...
Error:
    Internal libraries only supported with per-component builds.
    Per-component builds were disabled because program coverage is enabled
    In the package 'attoparsec-0.14.4'

peterbecich · 2022-05-15T06:47:16Z

I see this with Cabal 3.6.2.0 and Pandoc:

After cloning https://github.com/jgm/pandoc.git,

% cabal test --enable-coverage
Resolving dependencies...
Error:
    Internal libraries only supported with per-component builds.
    Per-component builds were disabled because program coverage is enabled
    In the package 'attoparsec-0.14.4'

The workaround #6440 (comment) does not appear to have an effect:

packages: *
tests: True
flags: +embed_data_files
constraints: aeson >= 2.0.1.0

-- coverage: True
-- library-coverage: False

package attoparsec
  coverage: False
  library-coverage: False

I've tried a couple variations on this cabal.project

I have also installed the latest version of Cabal (3.7.0.0) from this repository and tried that.

This does succeed:

cabal test --enable-coverage --disable-library-coverage

However, there are no .mix or .tix files created.

RyanGlScott · 2022-05-16T10:35:26Z

I think you're missing a key part of the workaround in #6440 (comment), which is the package * stanza:

package *
  coverage: True
  library-coverage: True

package attoparsec
  coverage: False
  library-coverage: False

If I add that and run cabal test (without specifying the --enable-coverage) flag, then I'm able to observe .mix and .tix files after running the pandoc test suite.

RyanGlScott · 2022-05-16T10:45:16Z

In fact, I don't think the workaround even requires disabling coverage for packages with internal libraries. I was also able to get coverage working using cabal test and this simpler configuration:

package *
  coverage: True
  library-coverage: True

Mikolaj · 2022-05-16T12:46:18Z

Probably --enable-coverage probably overrides anything in the project file, which would explain the observations.

jneira · 2022-05-16T12:58:19Z

--enable-coverage would override the options set in the config files for local packages, being equivalent to top level, out of any package stanza, coverage: true
in theory of course

peterbecich · 2022-05-21T05:59:14Z

#6440 (comment) @RyanGlScott you are correct, it works with Cabal 3.6.2.0 and

package *
  coverage: True
  library-coverage: True

and cabal test.

I see the .mix and .tix files

Thanks all

This commits re-enables per-component builds when coverage checking is enabled. This restriction was previously added in haskell#5004 to fix haskell#4798. However, the fix for haskell#5213, in haskell#7493, fixes the paths of the testsuite `.mix` files to the same location as that of the main library component, which in turn fixes haskell#4798 as well -- meaning the restriction to treat testsuites per-package (legacy-fallback) is no longer needed. Lifting this restriction additionally fixes haskell#6440 as we no longer constrain coverage to per-package builds only, thus allowing multi-libs. To generate hpc files in the appropriate component directories in the distribution tree, we move the hack from haskell#7493 from dictating the `.mix` directories where hpc information is stored to dictating the `.mix` directories that are included in the call to `hpc markup`. Fixes haskell#6440, and the already previously fixed haskell#4798, haskell#5213.

This commits re-enables per-component builds when coverage checking is enabled. This restriction was previously added in haskell#5004 to fix haskell#4798. However, the fix for haskell#5213, in haskell#7493, fixes the paths of the testsuite `.mix` files to the same location as that of the main library component, which in turn fixes haskell#4798 as well -- meaning the restriction to treat testsuites per-package (legacy-fallback) is no longer needed. Lifting this restriction additionally fixes haskell#6440 as we no longer constrain coverage to per-package builds only, thus allowing multi-libs. To generate hpc files in the appropriate component directories in the distribution tree, we move the hack from haskell#7493 from dictating the `.mix` directories where hpc information is stored to dictating the `.mix` directories that are included in the call to `hpc markup`. Includes regression tests for haskell#6440 and haskell#4798 (the test for haskell#5213 already exists) Fixes haskell#6440, and the already previously fixed haskell#4798, haskell#5213.

This commits re-enables per-component builds when coverage checking is enabled. This restriction was previously added in haskell#5004 to fix haskell#4798. However, the fix for haskell#5213, in haskell#7493, fixes the paths of the testsuite `.mix` files to the same location as that of the main library component, which in turn fixes haskell#4798 as well -- meaning the restriction to treat testsuites per-package (legacy-fallback) is no longer needed. 1. We allow hpc in per-component builds 2. To generate hpc files in the appropriate component directories in the distribution tree, we move the hack from haskell#7493 from dictating the `.mix` directories where hpc information is stored to dictating the `.mix` directories that are included in the call to `hpc markup`. We also drop an unnecessary directory in the hpc file hierarchy. 3. To account for internal libraries, we include the mix dirs and exposed modules of all (non-indefinite) libraries in the package 4. We only add non-indefinite libraries to the hpc markup command. Indefinite libraries and instantiations are ignored as it is not obvious what it means for HPC to support backpack, e.g. covering a library function that two different instantiations The combination of (1,3) fix haskell#6440, and adding (4) fixes haskell#6397 Includes regression tests for haskell#6440, haskell#6397, and haskell#4798 (the test for haskell#5213 already exists) Fixes haskell#6440, haskell#6397, and fixes in a new way the previously fixed haskell#4798, haskell#5213.

This commits re-enables per-component builds when coverage checking is enabled. This restriction was previously added in haskell#5004 to fix haskell#4798. - haskell#4798 was subsequently fixed "again" with the fix for haskell#5213, in haskell#7493 by fixing the paths of the testsuite `.mix` files to the same location as that of the main library component. Therefore the restriction to treat testsuites per-package (legacy-fallback) is no longer needed. We went further and fixed coverage for internal sublibraries, packages with backpack (but without generating coverage information for indefinite and instantiated units -- it is not clear what it would mean for HPC to support this), and coverage for multi-package projects. 1. We allow hpc in per-component builds 2. To generate hpc files in the appropriate component directories in the distribution tree, we remove the hack from haskell#7493 and instead determine the `.mix` directories that are included in the call to `hpc markup` by passing the list of libraries in the project from the cabal-install invocation of test. We also drop an unnecessary directory in the hpc file hierarchy. 3. To account for internal (non-backpack) libraries, we include the mix dirs and modules of all (non-indefinite and non-instantiations) libraries in the project Indefinite libraries and instantiations are ignored as it is not obvious what it means for HPC to support backpack, e.g. covering a library function that two different instantiations 4. We now only reject coverage if there are no libraries at all in the project, rather than if there are no libraries in the package. This allows us to drop the coverage masking logic in cabal.project.coverage while still having coverage of cabal-install (i.e. cabal test --enable-coverage cabal-install now works without the workaround) Even though we allow multi-package project coverage, we still cover each package independently -- the tix files resulting from all packages are not combined for the time being. Includes tests for haskell#6440, haskell#6397, haskell#8609, and haskell#4798 (the test for haskell#5213 already exists) Fixes haskell#6440 (internal libs coverage), haskell#6397 (backpack breaks coverage) , haskell#8609 (multi-package coverage report) and fixes in a new way the previously fixed haskell#4798, haskell#5213.

This commits re-enables per-component builds when coverage checking is enabled. This restriction was previously added in haskell#5004 to fix haskell#4798. - haskell#4798 was subsequently fixed "again" with the fix for haskell#5213, in haskell#7493 by fixing the paths of the testsuite `.mix` files to the same location as that of the main library component. Therefore the restriction to treat testsuites per-package (legacy-fallback) is no longer needed. We went further and fixed coverage for internal sublibraries, packages with backpack (but without generating coverage information for indefinite and instantiated units -- it is not clear what it would mean for HPC to support this), and coverage for multi-package projects. 1. We allow hpc in per-component builds 2. To generate hpc files in the appropriate component directories in the distribution tree, we remove the hack from haskell#7493 and instead determine the `.mix` directories that are included in the call to `hpc markup` by passing the list of libraries in the project from the cabal-install invocation of test. We also drop an unnecessary directory in the hpc file hierarchy. 3. To account for internal (non-backpack) libraries, we include the mix dirs and modules of all (non-indefinite and non-instantiations) libraries in the project Indefinite libraries and instantiations are ignored as it is not obvious what it means for HPC to support backpack, e.g. covering a library function that two different instantiations 4. We now only reject coverage if there are no libraries at all in the project, rather than if there are no libraries in the package. This allows us to drop the coverage masking logic in cabal.project.coverage while still having coverage of cabal-install (i.e. cabal test --enable-coverage cabal-install now works without the workaround) Even though we allow multi-package project coverage, we still cover each package independently -- the tix files resulting from all packages are not combined for the time being. TODO: Multi-package project coverage is fixed in Cabal, however, the paths to the source files listed in the `.mix` files will be incorrect because package sources will no longer be in the root of the project tree, but rather under the subdir with the package... Includes tests for haskell#6440, haskell#6397, haskell#8609, and haskell#4798 (the test for haskell#5213 already exists) Fixes haskell#6440 (internal libs coverage), haskell#6397 (backpack breaks coverage) , haskell#8609 (multi-package coverage report) and fixes in a new way the previously fixed haskell#4798, haskell#5213.

This commits re-enables per-component builds when coverage checking is enabled. This restriction was previously added in haskell#5004 to fix haskell#4798. - haskell#4798 was subsequently fixed "again" with the fix for haskell#5213, in haskell#7493 by fixing the paths of the testsuite `.mix` files to the same location as that of the main library component. Therefore the restriction to treat testsuites per-package (legacy-fallback) is no longer needed. We went further and fixed coverage for internal sublibraries, packages with backpack (but without generating coverage information for indefinite and instantiated units -- it is not clear what it would mean for HPC to support this), and coverage for multi-package projects. 1. We allow hpc in per-component builds 2. To generate hpc files in the appropriate component directories in the distribution tree, we remove the hack from haskell#7493 and instead determine the `.mix` directories that are included in the call to `hpc markup` by passing the list of components in the project from the cabal-install invocation of test. We also drop an unnecessary directory in the hpc file hierarchy. 3. To account for internal (non-backpack) libraries, we include the mix dirs and modules of all (non-indefinite and non-instantiations) libraries in the project Indefinite libraries and instantiations are ignored as it is not obvious what it means for HPC to support backpack, e.g. covering a library function that two different instantiations 4. We now only reject coverage if there are no libraries at all in the project, rather than if there are no libraries in the package. This allows us to drop the coverage masking logic in cabal.project.coverage while still having coverage of cabal-install (i.e. cabal test --enable-coverage cabal-install now works without the workaround) Even though we allow multi-package project coverage, we still cover each package independently -- the tix files resulting from all packages are not combined for the time being. TODO: Multi-package project coverage is fixed in Cabal, however, the paths to the source files listed in the `.mix` files will be incorrect because package sources will no longer be in the root of the project tree, but rather under the subdir with the package... Includes tests for haskell#6440, haskell#6397, haskell#8609, and haskell#4798 (the test for haskell#5213 already exists) Fixes haskell#6440 (internal libs coverage), haskell#6397 (backpack breaks coverage) , haskell#8609 (multi-package coverage report) and fixes in a new way the previously fixed haskell#4798, haskell#5213.

This commit re-designs the mechanism by which we make the .mix files of libraries available to produce the Haskell Program Coverage report after running testsuites. The idea, for the Cabal library, is: * Cabal builds libraries with -fhpc, and store the hpc artifacts in build </> `extraCompilationArtifacts` * At Cabal install time, `extraCompilationArtifacts` is copied into the package database * At Cabal configure time, we both - receive as --coverage-for flags unit-ids of library components from the same package (ultimately, when haskell#9493 is resolved, we will receive unit ids of libraries in other packages in the same project too), - and, when configuring a whole package instead of just a testsuite component, we determine the unit-ids of libraries in the package these unit-ids are written into `configCoverageFor` in `ConfigFlags` * At Cabal test time, for each library to cover (stored in `configCoverageFor`), we look in the package database for the hpc dirs, which we eventually pass along to the `hpc markup` call as `--hpcdir` flags As for cabal-install: * After a plan has been elaborated, we select the packages which can be covered and pass them to Cabal's ./Setup configure as --coverage-for=<unit-id> flags. - Notably, valid libraries are non-indefinite and non-instantiations, since HPC does not support backpack. - Furthermore, we only include libraries in the same package as the component being configured, despite possibly there being more library components in other packages of the same project. When haskell#9493 is resolved, we could lift this restriction and pass all libraries local to the package as --coverage-for. See `determineCoverageFor` and `shouldCoverPkg` in Distribution.Client.ProjectPlanning. Detail: We no longer pass the path to the testsuite's mix dirs to `hpc markup` because we only ever include modules in libraries, which means they were previously unused. Fixes haskell#6440 (internal libs coverage), haskell#6397 (backpack breaks coverage), doesn't yet fix haskell#8609 (multi-package coverage report) which is tracked in haskell#9493, and fixes in a new way the previously fixed haskell#4798, haskell#5213.

This commits re-enables per-component builds when coverage checking is enabled. This restriction was previously added in haskell#5004 to fix haskell#4798. - haskell#4798 was subsequently fixed "again" with the fix for haskell#5213, in haskell#7493 by fixing the paths of the testsuite `.mix` files to the same location as that of the main library component. Therefore the restriction to treat testsuites per-package (legacy-fallback) is no longer needed. We went further and fixed coverage for internal sublibraries, packages with backpack (but without generating coverage information for indefinite and instantiated units -- it is not clear what it would mean for HPC to support this), and coverage for multi-package projects. 1. We allow hpc in per-component builds 2. To generate hpc files in the appropriate component directories in the distribution tree, we remove the hack from haskell#7493 and instead determine the `.mix` directories that are included in the call to `hpc markup` by passing the list of components in the project from the cabal-install invocation of test. We also drop an unnecessary directory in the hpc file hierarchy. 3. To account for internal (non-backpack) libraries, we include the mix dirs and modules of all (non-indefinite and non-instantiations) libraries in the project Indefinite libraries and instantiations are ignored as it is not obvious what it means for HPC to support backpack, e.g. covering a library function that two different instantiations 4. We now only reject coverage if there are no libraries at all in the project, rather than if there are no libraries in the package. This allows us to drop the coverage masking logic in cabal.project.coverage while still having coverage of cabal-install (i.e. cabal test --enable-coverage cabal-install now works without the workaround) Even though we allow multi-package project coverage, we still cover each package independently -- the tix files resulting from all packages are not combined for the time being. Multi-package project coverage is fixed in Cabal, however, the paths to the source files listed in the `.mix` files will be incorrect because package sources will no longer be in the root of the project tree, but rather under the subdir with the package. We add an error for multi-package projects when coverage is enabled, and track lifting this error in haskell#9493. Includes tests for haskell#6440, haskell#6397, haskell#8609, and haskell#4798 (the test for haskell#5213 already exists) Fixes haskell#6440 (internal libs coverage), haskell#6397 (backpack breaks coverage) , doesn't yet fix haskell#8609 (multi-package coverage report) and fixes in a new way the previously fixed haskell#4798, haskell#5213.

This commit re-designs the mechanism by which we make the .mix files of libraries available to produce the Haskell Program Coverage report after running testsuites. The idea, for the Cabal library, is: * Cabal builds libraries with -fhpc, and store the hpc artifacts in build </> `extraCompilationArtifacts` * At Cabal install time, `extraCompilationArtifacts` is copied into the package database * At Cabal configure time, we both - receive as --coverage-for flags unit-ids of library components from the same package (ultimately, when haskell#9493 is resolved, we will receive unit ids of libraries in other packages in the same project too), - and, when configuring a whole package instead of just a testsuite component, we determine the unit-ids of libraries in the package these unit-ids are written into `configCoverageFor` in `ConfigFlags` * At Cabal test time, for each library to cover (stored in `configCoverageFor`), we look in the package database for the hpc dirs, which we eventually pass along to the `hpc markup` call as `--hpcdir` flags As for cabal-install: * After a plan has been elaborated, we select the packages which can be covered and pass them to Cabal's ./Setup configure as --coverage-for=<unit-id> flags. - Notably, valid libraries are non-indefinite and non-instantiations, since HPC does not support backpack. - Furthermore, we only include libraries in the same package as the component being configured, despite possibly there being more library components in other packages of the same project. When haskell#9493 is resolved, we could lift this restriction and pass all libraries local to the package as --coverage-for. See `determineCoverageFor` and `shouldCoverPkg` in Distribution.Client.ProjectPlanning. Detail: We no longer pass the path to the testsuite's mix dirs to `hpc markup` because we only ever include modules in libraries, which means they were previously unused. Fixes haskell#6440 (internal libs coverage), haskell#6397 (backpack breaks coverage), doesn't yet fix haskell#8609 (multi-package coverage report) which is tracked in haskell#9493, and fixes in a new way the previously fixed haskell#4798, haskell#5213.

peterbecich · 2024-02-18T08:10:50Z

Can this issue be re-opened? I believe this work-around is still necessary: #6440 (comment)

dpwiz · 2024-02-27T09:45:25Z

Yep, it is. Came here right after hitting the attoparsec error.

This commits re-enables per-component builds when coverage checking is enabled. This restriction was previously added in haskell#5004 to fix haskell#4798. - haskell#4798 was subsequently fixed "again" with the fix for haskell#5213, in haskell#7493 by fixing the paths of the testsuite `.mix` files to the same location as that of the main library component. Therefore the restriction to treat testsuites per-package (legacy-fallback) is no longer needed. We went further and fixed coverage for internal sublibraries, packages with backpack (but without generating coverage information for indefinite and instantiated units -- it is not clear what it would mean for HPC to support this), and coverage for multi-package projects. 1. We allow hpc in per-component builds 2. To generate hpc files in the appropriate component directories in the distribution tree, we remove the hack from haskell#7493 and instead determine the `.mix` directories that are included in the call to `hpc markup` by passing the list of components in the project from the cabal-install invocation of test. We also drop an unnecessary directory in the hpc file hierarchy. 3. To account for internal (non-backpack) libraries, we include the mix dirs and modules of all (non-indefinite and non-instantiations) libraries in the project Indefinite libraries and instantiations are ignored as it is not obvious what it means for HPC to support backpack, e.g. covering a library function that two different instantiations 4. We now only reject coverage if there are no libraries at all in the project, rather than if there are no libraries in the package. This allows us to drop the coverage masking logic in cabal.project.coverage while still having coverage of cabal-install (i.e. cabal test --enable-coverage cabal-install now works without the workaround) Even though we allow multi-package project coverage, we still cover each package independently -- the tix files resulting from all packages are not combined for the time being. Multi-package project coverage is fixed in Cabal, however, the paths to the source files listed in the `.mix` files will be incorrect because package sources will no longer be in the root of the project tree, but rather under the subdir with the package. We add an error for multi-package projects when coverage is enabled, and track lifting this error in haskell#9493. Includes tests for haskell#6440, haskell#6397, haskell#8609, and haskell#4798 (the test for haskell#5213 already exists) Fixes haskell#6440 (internal libs coverage), haskell#6397 (backpack breaks coverage) , doesn't yet fix haskell#8609 (multi-package coverage report) and fixes in a new way the previously fixed haskell#4798, haskell#5213.

This commit re-designs the mechanism by which we make the .mix files of libraries available to produce the Haskell Program Coverage report after running testsuites. The idea, for the Cabal library, is: * Cabal builds libraries with -fhpc, and store the hpc artifacts in build </> `extraCompilationArtifacts` * At Cabal install time, `extraCompilationArtifacts` is copied into the package database * At Cabal configure time, we both - receive as --coverage-for flags unit-ids of library components from the same package (ultimately, when haskell#9493 is resolved, we will receive unit ids of libraries in other packages in the same project too), - and, when configuring a whole package instead of just a testsuite component, we determine the unit-ids of libraries in the package these unit-ids are written into `configCoverageFor` in `ConfigFlags` * At Cabal test time, for each library to cover (stored in `configCoverageFor`), we look in the package database for the hpc dirs, which we eventually pass along to the `hpc markup` call as `--hpcdir` flags As for cabal-install: * After a plan has been elaborated, we select the packages which can be covered and pass them to Cabal's ./Setup configure as --coverage-for=<unit-id> flags. - Notably, valid libraries are non-indefinite and non-instantiations, since HPC does not support backpack. - Furthermore, we only include libraries in the same package as the component being configured, despite possibly there being more library components in other packages of the same project. When haskell#9493 is resolved, we could lift this restriction and pass all libraries local to the package as --coverage-for. See `determineCoverageFor` and `shouldCoverPkg` in Distribution.Client.ProjectPlanning. Detail: We no longer pass the path to the testsuite's mix dirs to `hpc markup` because we only ever include modules in libraries, which means they were previously unused. Fixes haskell#6440 (internal libs coverage), haskell#6397 (backpack breaks coverage), doesn't yet fix haskell#8609 (multi-package coverage report) which is tracked in haskell#9493, and fixes in a new way the previously fixed haskell#4798, haskell#5213.

ivanperez-keera · 2024-09-16T01:04:08Z

The attoparsec error is the reason why copilot-language is not running the tests on hackage, by the way: https://hackage.haskell.org/package/copilot-language-4.0/reports/1/test

Mikolaj mentioned this issue Jul 24, 2021

cabal new-test doesn't work with library-coverage for components with other-modules #5213

Closed

gbaz added Cabal: code-coverage type: bug labels Sep 3, 2021

tfausak mentioned this issue Apr 13, 2022

Remove internal library haskell/attoparsec#210

Closed

peterbecich mentioned this issue May 15, 2022

README: Note that cabal does support coverage with 3.6.0.0 or later GaloisInc/crucible#884

Closed

andreasabel added the re: internal library Concerning internal libraries in packages label Feb 4, 2023

ulysses4ever added can-workaround There is a (maybe partial) workaround for the issue or missing feature and removed can-workaround There is a (maybe partial) workaround for the issue or missing feature labels Nov 10, 2023

brendanrbrown mentioned this issue Nov 22, 2023

PLT-8605: Code coverage support IntersectMBO/cardano-node-emulator#8

Merged

10 tasks

alt-romes mentioned this issue Nov 22, 2023

Allow per-component builds with coverage enabled #9464

Merged

5 tasks

mergify bot closed this as completed in 073ccc8 Dec 18, 2023

ivanperez-keera mentioned this issue Dec 28, 2023

Replicating coverage report on user side haskell/hackage-server#1278

Open

brianjosephmckeon mentioned this issue Feb 6, 2024

Tests not running on hackage byteverse/scientific-notation#8

Open

andreabedini reopened this Feb 18, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Coverage does not work for packages that use internal libraries or library components #6440

Coverage does not work for packages that use internal libraries or library components #6440

newhoggy commented Dec 16, 2019

symbiont-sam-halliday commented Mar 23, 2020 •

edited

Loading

symbiont-sam-halliday commented Mar 26, 2020 •

edited

Loading

ivanperez-keera commented May 7, 2022

peterbecich commented May 15, 2022 •

edited

Loading

RyanGlScott commented May 16, 2022

RyanGlScott commented May 16, 2022

Mikolaj commented May 16, 2022

jneira commented May 16, 2022

peterbecich commented May 21, 2022

peterbecich commented Feb 18, 2024

dpwiz commented Feb 27, 2024

ivanperez-keera commented Sep 16, 2024 •

edited

Loading

Coverage does not work for packages that use internal libraries or library components #6440

Coverage does not work for packages that use internal libraries or library components #6440

Comments

newhoggy commented Dec 16, 2019

symbiont-sam-halliday commented Mar 23, 2020 • edited Loading

symbiont-sam-halliday commented Mar 26, 2020 • edited Loading

ivanperez-keera commented May 7, 2022

peterbecich commented May 15, 2022 • edited Loading

RyanGlScott commented May 16, 2022

RyanGlScott commented May 16, 2022

Mikolaj commented May 16, 2022

jneira commented May 16, 2022

peterbecich commented May 21, 2022

peterbecich commented Feb 18, 2024

dpwiz commented Feb 27, 2024

ivanperez-keera commented Sep 16, 2024 • edited Loading

symbiont-sam-halliday commented Mar 23, 2020 •

edited

Loading

symbiont-sam-halliday commented Mar 26, 2020 •

edited

Loading

peterbecich commented May 15, 2022 •

edited

Loading

ivanperez-keera commented Sep 16, 2024 •

edited

Loading