Program coverage crashes in cabal new-test #4798
Assignees
Comments
|
@ttuegel is the one most knowledgeable about these bits of Cabal. |
|
I’ll try to dig into it / help however I can to facilitate... I’m just not
familiar with this stuff :)
…On Wed, Sep 27, 2017 at 4:25 PM Mikhail Glushenkov ***@***.***> wrote:
@ttuegel <https://github.com/ttuegel> is the one most knowledgeable about
these bits of Cabal.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4798 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAQwuubmcpKOkk9K_XgpoUXonnXE6qwks5smq8_gaJpZM4PmOv6>
.
|
|
@cartazio The test suite log doesn't contain any errors, but my build dir definitely doesn't contain a E: Manually moving the files to the expected location results in successful generation of coverage reports. It looks like this is the issue.: |
|
Ok, last update. It looks like the real issue is caused by bad arguments in this use of hpc markup. The last This is what it uses
This is what it should actually be
Incorrect invocation in full
E: Can confirm that normal |
|
so either |
|
it seems that cabal new-test didn't adjust how args/paths are passed to the the markup routines that invoke hpc... though @EButlerIV and i are really just poking around and guessing atm :) that is: when we build ghc programs with coverage, /Users/eugene/Development/Personal/blah/u2f-0.1.0.1/dist-newstyle/build/x86_64-osx/ghc-8.0.2/u2f-0.1.0.1/c/hspec-suite/hpc/prof/mix/u2f-0.1.0.1 should be setup properly ... or something |
|
@23Skidoo would fixing this be also a bug fix for 2.0 series cabal :) |
|
a) possible culprit: program coverage flags not set correctly for new build in general? is the results of |
It depends on how hard it will be to backport. |
|
The root of this issue is that the wrong build directory is being passed to the test phase. The test phase is getting |
|
One more thing: even if I can fix that, there is the underlying problem that each component now has a different build directory, which is incompatible with the existing API of |
|
@ttuegel if myself chang and Eugene can help please layout how we can!
A fix for master would probably still be a great improvement. And we could
help figuring out a backport once we see the diff.
In 2.0 they’re all in the same component afaict so it should be a simpler
version of the same fix I think
…On Thu, Oct 12, 2017 at 9:35 AM Thomas Tuegel ***@***.***> wrote:
One more thing: even if I can fix that, there is the underlying problem
that each component now has a different build directory, which is
incompatible with the existing API of hpcDir. In other words, I could not
backport this hypothetical bug fix to Cabal 2.0.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4798 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAQwjFqvHt7UHGWj568ZG1sDs--BE0Eks5srhWvgaJpZM4PmOv6>
.
|
|
Oh, I guess the problem here makes sense: for a non-Custom setup, new-test will create separate build directories for the library and test (like, literally separate, with each having their own LocalBuildInfo). And I guess the coverage mechanism was never clued in about how to deal with this. So this is more of a feature request. One way to work around the problem, then, is to turn off per-component build. I think there are some knobs for this, but you can at least easily check by changing the build-type to Custom. |
@cartazio |
|
attached is a full log the bit at the end in particular is |
|
@cj285 Could you please also post the output of |
|
This is the result of |
|
Let us know if there’s any further information we can provide or other ways
we can help
…On Wed, Oct 18, 2017 at 10:43 AM Chang Yang Jiao ***@***.***> wrote:
This is the result of find dist-newstyle -name hpc
~/enterprise-simple-server ((323160c7…)|…) $ find dist-newstyle -name hpc
dist-newstyle/build/x86_64-osx/ghc-8.2.1/enterprise-simple-server-0.1.0.0/c/testsuite/hpc
dist-newstyle/build/x86_64-osx/ghc-8.2.1/enterprise-simple-server-0.1.0.0/hpc
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4798 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAQwl62QSaQ8l2oP44VTtpcymJzykPFks5stg57gaJpZM4PmOv6>
.
|
I know what the problem is and I have a solution, but I am blocked on testing by not having a working Cabal installation at the moment due to other bugs. |
|
Any way I or others can help? (I do really want this fix and now happy to
help however I can )
…On Tue, Oct 24, 2017 at 2:46 PM Thomas Tuegel ***@***.***> wrote:
Let us know if there’s any further information we can provide or other
ways we can help
I know what the problem is and I have a solution, but I am blocked on
testing by not having a working Cabal installation at the moment due to
other bugs.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4798 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAQwvDHP0jJ1qpSAHasqPQND5aBDhpUks5svjCAgaJpZM4PmOv6>
.
|
|
Not really... I "only" need to figure out how to get the build path information into the right places. At the moment, per-component build is a problem: when we're running the test component, the library component isn't in scope, so we can't determine the library build directory, so we can't pass the correct HPC directories to the test runner. The easy solution is to disable per-component build when coverage is requested. How badly would this impact you? |
ttuegel
added a commit
to ttuegel/cabal
that referenced
this issue
Nov 22, 2017
Creating the test program coverage report requires the test runner to know the build directory for the library component. If per-component builds are enabled, this is not possible because the library is not in-scope at the same time as the test component. The only apparent solution that does not require rethinking per-component builds entirely is to disable it when coverage is enabled. Resolves: haskell#4798
4 tasks
|
it wouldnt hurt me currently because interacting with components is barely
documented yet :)
But i do think long term having those be at odds is a shame/ sounds like a
missfeature ...
it sounds like separate components are treated as independent except when
one depends on the other as a library?
can cabal 2.0 builds export two libraries, or just one public library?
…On Tue, Nov 21, 2017 at 9:38 AM, Thomas Tuegel ***@***.***> wrote:
Not really... I "only" need to figure out how to get the build path
information into the right places.
At the moment, per-component build is a problem: when we're running the
test component, the library component isn't in scope, so we can't determine
the library build directory, so we can't pass the correct HPC directories
to the test runner.
The easy solution is to disable per-component build when coverage is
requested. How badly would this impact you?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4798 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAQwoeLEjN6zo9Ep7EXpObTQXtjZ5yKks5s4uBlgaJpZM4PmOv6>
.
|
ttuegel
added a commit
to ttuegel/cabal
that referenced
this issue
Nov 27, 2017
Creating the test program coverage report requires the test runner to know the build directory for the library component. If per-component builds are enabled, this is not possible because the library is not in-scope at the same time as the test component. The only apparent solution that does not require rethinking per-component builds entirely is to disable it when coverage is enabled. Resolves: haskell#4798
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 5, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 7, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 7, 2023
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.
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 7, 2023
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.
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 7, 2023
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.
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 7, 2023
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.
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 7, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 8, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 8, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 8, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 8, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 8, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 8, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 8, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 11, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 11, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 11, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 11, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 11, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 11, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 11, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 11, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 12, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 12, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 12, 2023
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.
andreabedini
pushed a commit
to alt-romes/cabal
that referenced
this issue
Dec 18, 2023
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.
andreabedini
pushed a commit
to alt-romes/cabal
that referenced
this issue
Dec 18, 2023
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.
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Dec 18, 2023
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.
erikd
pushed a commit
to erikd/cabal
that referenced
this issue
Apr 22, 2024
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.
erikd
pushed a commit
to erikd/cabal
that referenced
this issue
Apr 22, 2024
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@cartazio was looking through this with me and can reproduce the same issue
we are using ghc 8.2.1 and cabal new-build / new-test
a verbose (-v3) output would be as follows
we can make the simple application code available to any cabal maintainer privately (well, @cartazio will deal with that), but can't make it public at the moment, (its a pretty small project, but minimizing this failure would require more ideas about how cabal works than we do! :) )
The text was updated successfully, but these errors were encountered: