cabal new-test doesn't work with library-coverage for components with other-modules #5213
Assignees
Milestone
Comments
|
A minimal reproducer can be found at https://github.com/RyanGlScott/cabal-gh5213: |
|
It's worth noting that I'm not sure why |
|
I quick whereas it should have been looking at for reference, the flags in my case were: So it appears that cabal is not passing the right
We're indeed missing the In other words, the erroneously pointing into the test-components build-dir, should instead have been pointing to the library component's build-dir. The more I investigate, the more issues/tech-debt I notice... :-/ |
This was referenced Jul 25, 2018
|
I forgot to tackle this in time for 2.4, but I'll try to get to this within the next 1-2 weeks; but it's probably not going to be ready in time for the cabal-install 2.4.0.0 rls; more like 2.4.1.0 |
|
Thanks @hvr. |
|
Just hit this myself with cabal 2.4.1.0. Is that expected? |
|
"Expected" in the sense that it's a known issue, yes. |
|
#4798 is related right? |
|
a related problem folks with fancy code setups hit is when they try to do coverage and have local/not hackage deps, and naively cabal tries do enable coverage on the local package. the work around for now is to set --disable-coverage for that local dep in the cabal.project file. But i think thats an issue that might be related. but probably merits its own ticket |
|
quoting @davean a near term improvment would be ANY sort of warning saying "this is a known issue, heres what you need to do " |
|
cc @ocharles |
|
This quite likely got fixed in #7250 and/or #7358, which are both merged. Could somebody please check, e.g., using a dev releast that can be obtained as in #7458 (comment)? |
|
I downloaded a However, I am still able to reproduce the bug when using the minimal example from #5213 (comment): |
|
@RyanGlScott: thank you very much for verifying. A similar issue turned out to be fixed by the PRs but this one still holds. Good to know and since it's already marked as high priority, just a shout out to whomever feels heroic enough to tackle it. I dare say, with the recent changes, it may be easier to diagnose and code-dive now. |
|
BTW, once the crash (probably caused by wrong paths given to hpc, as @hvr discovered) is fixed, are cabal/Cabal/src/Distribution/Simple/Hpc.hs Lines 116 to 119 in f0d0594 but I think I'd be interested in dead or not tested enough code in my hidden library modules as well. OTOH, perhaps people are only interested in whether their tests hit all API entry points and don't care about particular code paths? Edit: I think Edit2: the line from which the wrong hpc paths come is It should probably be instead, but that's only a guess. Edit3: but it doesn't typecheck. Edit4: and it's unused in the code path from the repro. One of the places using Edit5: the place is Edit6: this typechecks fine in ExeV10.runTest: where but the path is actually the same as the old one, probably because that is a Edit7: oh noes, this is a single Edit8: |
|
I'm stuck at this point. I can't find the A crude way would be to just remove Hints welcome. |
|
Ok so this is the offending bit: And we need to calculate and pass a second distPref as well, for the lib component. The correct dir is accidentally (in a sense) the dataDir of the LocalBuildInfo. A hack would be to use that. A more correct thing would be to put a (potentially list) of dirs in the localBuildInfo for hpcdirs, calculated just as the dataDir is, but not risking being overridden by some flag. In either case, its the LocalBuildInfo and not the ComponentLocalBuildInfo that I think should be modified/used. |
|
Given that and nowhere else is, e.g., Edit: to spell it out, the think I hope I'm missing is the correct directory (such as |
|
I think its fine for now to rely on ghc's behavior here. Arguably we should upstream flags to ghc so that we can control where mix files end up (it seems hardwired for now) but I'm fine hardcoding in something that matches ghc's hardcoding for now. cc @bgamari |
|
Note to self (I'm not stuck): I think I've fixed the place in the code that we suspected of being buggy, but it still fails and in the same way. I think I was right the correct directory is not created in cabal code, but I think I was wrong it's created (hardwired) in GHC --- in fact, it seems we create the director via calls to |
Mikolaj
added a commit
to Mikolaj/cabal
that referenced
this issue
Jul 24, 2021
3 tasks
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
I'll work on preparing a minimal example in a bit. In the meantime, you can trigger this issue with
scotty-0.11.0:This error doesn't happen for another project,
wai-middleware-static-0.8.1. Unlikescotty,wai-middleware-statichas noother-modules, so I suspect that is the culprit here.The text was updated successfully, but these errors were encountered: