Handle Backpack signature files in component discovery

[philippedev101]

Addresses #6937.

@mpilgrem I don't think .hsig should go through the custom-preprocessor path. A .hsig file is already the source file for a Backpack signature, not an input that should produce a .hs file.

The main user-visible change is that a normal Backpack package should stop getting a warning that suggests adding .hsig to custom-preprocessor-extensions. That warning sends people in the wrong direction: the project is not missing preprocessor configuration, Stack just needs to recognize the declared signature file as part of the package.

There are now three cases. If the module is listed in signatures, Stack treats the .hsig as expected and stays quiet. If there is a local .hsig file but the module is not listed in signatures, Stack gives a Backpack-specific hint pointing at the missing field. If the file really is some other unknown extension, Stack still gives the existing custom-preprocessor warning.

The declared .hsig files are also tracked for rebuilds, so changing a signature is treated like changing another source file that matters to the component.

Tests cover the valid Backpack case, .hsig rebuild tracking, the undeclared-signature warning, and the unchanged custom-preprocessor warning path.

[mpilgrem]

@philippedev101, I've set the pull request to draft while the integration tests are failing.

In the case of backpack-x-pkg-transitive, the test expects stack build to work if the Logger.hsig has been changed (to add loggerName :: String). In fact, it fails with:

> stack build
Warning: Found Backpack signature file for Cabal entry Str, but that module is not listed in the component's signatures field:
         * Str.hsig

         If this file is meant to be a Backpack signature, add Str to the signatures field in the package description.

Warning: Backpack: no dependency exposes module Str needed to instantiate str-sig. Ensure the implementing package is listed in build-depends.
consumer-pkg-0.0.0: unregistering (missing dependencies: logger-sig)
logger-sig-0.0.0: unregistering (local file changes: src\Logger.hsig)
logger-sig-0.0.0: unregistering (local file changes: src\Logger.hsig)
str-sig-0.0.0: unregistering
str-sig-0.0.0: unregistering
logger-sig  > build (lib) with ghc-9.10.3
logger-sig  > Preprocessing library for logger-sig-0.0.0...
logger-sig  > Building library instantiated with
logger-sig  >   Logger = <Logger>
logger-sig  >   Str = <Str>
logger-sig  > for logger-sig-0.0.0...
logger-sig  > <command line>: cannot satisfy -package-id str-sig-0.0.0-HPF0111dNK1KIRtIq2ktMM[Str=<Str>]
logger-sig  >     (use -v for more information)
str-sig     > configure (lib)
str-sig     > Configuring str-sig-0.0.0...
str-sig     > Error: [Cabal-5000]
str-sig     > The following package dependencies were requested
str-sig     >     --dependency='str-sig=str-sig-0.0.0-HPF0111dNK1KIRtIq2ktMM'
str-sig     > however the given installed package instance does not exist.
str-sig     >

As this behaviour was the same before the fix of #6937, I have given it its own issue:

• Second stack build fails, if *.hsig file is changed #6941

[mpilgrem]

I rebased on master and fixed the other (new) integration test backpack-undeclared-signature-warning.

[mpilgrem]

@philippedev101, I'm keen not to lose momentum for Backpack-supporting Stack. Do you know if the failing CI is a problem with the original implementation of Backpack support or a problem with the changed backpack-x-pkg-transitive integration test?

[philippedev101]

Thanks for digging into this. And the extra ping because i lost sight of it. I agree it is important to catch this kind of Backpack issue before the next release.

I investigated the failing backpack-x-pkg-transitive case, and my conclusion is that it exposes a problem in the original Backpack planning rather than a problem with the changed integration test or with the .hsig discovery fix in this PR.

The short version is that Stack sometimes needs Package metadata for an already-installed indefinite package so it can create a Backpack CInst task. The previous planning shape got that metadata by treating the installed package more like an ADRToInstall task, but that can make a clean installed signature library participate in rebuild/unregister decisions as if it were a normal package to build. That is what leads to the stale/missing unit-id behavior.

I opened a follow-up PR that keeps installed signature packages as ADRFound, loads separate source-backed templates only for CInst construction, and adds regression coverage for the dirty and inherited-hole cases.