Skip to content

Commit 8966469

Browse files
committed
Update copilot instructions to ignore imports using same alias.
1 parent 4920ad5 commit 8966469

1 file changed

Lines changed: 10 additions & 0 deletions

File tree

.github/copilot-instructions.md

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,16 @@ import Cardano.Api.Experimental.Tx qualified as Exp
1111

1212
This is valid GHC Haskell both modules are accessible via the `Exp.` prefix. Name resolution happens at the use site; ambiguity only arises if both modules export the same identifier and it is used without disambiguation. Do **not** flag this pattern as a compile error or suggest renaming an alias unless there is an actual ambiguity at a specific use site.
1313

14+
Even when several same-alias modules export the same **name**, there is still no ambiguity if they denote the same original entity. Re-exports are the norm in this codebase: `Cardano.Api.Ledger` re-exports large parts of `Cardano.Ledger.Api` and `Cardano.Ledger.BaseTypes`, and all three are conventionally imported qualified as `L`:
15+
16+
```haskell
17+
import Cardano.Api.Ledger qualified as L
18+
import Cardano.Ledger.Api qualified as L
19+
import Cardano.Ledger.BaseTypes qualified as L
20+
```
21+
22+
A use like `L.SNothing` or `L.Tx` resolves to a single entity because every import chain leads back to the same defining module. GHC rejects a use site only when the same name refers to **different** entities. Do **not** claim such code "should fail to compile" CI compiles every module with `-Wall -Werror` including `-Wunused-imports`, so if the code is merged or the build is green, the imports are neither ambiguous nor redundant. Do **not** suggest dropping one of the imports as "redundant" either: each import typically contributes names the others do not re-export, and a genuinely redundant import would already fail the zero-warning build.
23+
1424
## Cabal File Formatting
1525

1626
In `.cabal` files, all top-level package metadata fields (`name:`, `version:`, `synopsis:`, `description:`, `copyright:`, `author:`, `maintainer:`, `license:`, `build-type:`, etc.) are written at column 0 with no leading indentation. This is the standard Cabal format. Do **not** flag these fields as having inconsistent indentation.

0 commit comments

Comments
 (0)