cabal Only munge internal dependencies when printing when there is no explicit syntax

Only munge internal dependencies when printing when there is no explicit syntax

Open mpickering opened this issue 1 year ago • 2 comments

Only munge internal dependencies when printing when there is no explicit syntax

In postProcessInternalDeps the shadowing logic which existed prior to cabal format 3.4 is implemented in a post processing step.

The algorithm there replaces any references to internal sublibraries with an explicit qualifier. For example if you write..
```
library build-depends: foo

library foo ... 
```
this is reinterpreted as
```
library build-depends: mylib:foo

library foo ... 
```
In preProcessInternalDeps the inverse transformation takes place, the goal is to replace mylib:foo with just foo.
Things go wrong if you are using version 3.0 for your cabal file because
- In 3.0 the qualifier syntax is introduced so you can be expliciit about sublibrary dependencies
- The shadowing semantics of non-qualified dependencies still exists.
So the situation is that the user is explicit about the sublibrary
```
library

library qux
  build-depends: mylib:{mylib, foo}

library foo
```
1. Post-process leaves this alone, the user is already explicit about depending on a sublibrary.
2. Pre-processing then rewrites mylib:{mylib, foo} into two dependencies, mylib and foo (no qualifier).
3. When parsed these are two separate dependencies rather than treated as one dependency, roundtrip test fails.

Solution: Only perform the reverse transformation when the cabal library version is <= 3.0 and doesn't support the explicit syntax.

Now what happens in these two situations:

library build-depends: foo

library foo ...

this is reinterpreted as

library
  build-depends: mylib:foo

library foo
  ...

then printed and parsed exactly the same way.

Note: Mixins only supported sublibrary qualifiers from 3.4 whilst dependencies supported this from 3.0, hence the lack of guard on the mixins case.

Fixes #10283

Please read Github PR Conventions and then fill in one of these two templates.

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

[x] Patches conform to the coding conventions.
[x] Any changes that could be relevant to users have been recorded in the changelog.
[x] The documentation has been updated, if necessary.
[x] Manual QA notes have been included.
[x] Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

Template B: This PR does not modify behaviour or interface

E.g. the PR only touches documentation or tests, does refactorings, etc.

Include the following checklist in your PR:

[ ] Patches conform to the coding conventions.
[ ] Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).

Aug 27 '24 16:08 mpickering