GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-28T19:14:27Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24483Can't re-export duplicate field names from identical constructor names2024-03-28T19:14:27ZTom EllisCan't re-export duplicate field names from identical constructor namesThis is a new ticket to track [an issue explained by @adamgundry](https://gitlab.haskell.org/ghc/ghc/-/issues/13352#note_294968) in a prior (closed) ticket. That is, the following code leads to the following error. The error is still pr...This is a new ticket to track [an issue explained by @adamgundry](https://gitlab.haskell.org/ghc/ghc/-/issues/13352#note_294968) in a prior (closed) ticket. That is, the following code leads to the following error. The error is still present as of GHC 9.8. It seems like an artificial limitation and it would be great if it could be lifted. This is particularly annoying if we want to create a custom `Prelude`. It makes it impossible to create a custom `Prelude` containing two different fields with the same name, if their constructors also share the same name.
```
{-# LANGUAGE DuplicateRecordFields #-}
module A where
data S = C { foo :: Int }
{-# LANGUAGE DuplicateRecordFields #-}
module B where
data T = C { foo :: Int }
{-# LANGUAGE DuplicateRecordFields #-}
module C (S(foo), T(foo)) where
import A (S(..))
import B (T(..))
```
```
Conflicting exports for ‘foo’:
‘S(foo)’ exports ‘foo’
imported from ‘A’ at C.hs:5:28-32
(and originally defined at A.hs:3:16-18)
‘T(foo)’ exports ‘foo’
imported from ‘B’ at C.hs:6:28-32
(and originally defined at B.hs:5:14-16)
```
----
It's also an interesting puzzle to try to imagine the implementation details that allow both `foo`s to be used within the same module but not re-exported from the same module! I haven't been able to work it out ...
EDIT: Ah, I think I have an explanation: in a given module, duplicate field names are disambiguated by the module they were imported from plus the constructor name.https://gitlab.haskell.org/ghc/ghc/-/issues/24452Confusing "Ambiguous occurrence" error message in the presence of qualified i...2024-02-20T15:05:23ZRyan ScottConfusing "Ambiguous occurrence" error message in the presence of qualified importsCompiling this program:
```hs
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
module Bug where
import Control.Applicative (Alternative)
import qualified Data.Map as Map
import qualified Data.Set as Set
newtype Foo a = MkFoo [a] deriving (...Compiling this program:
```hs
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
module Bug where
import Control.Applicative (Alternative)
import qualified Data.Map as Map
import qualified Data.Set as Set
newtype Foo a = MkFoo [a] deriving (Functor, Applicative)
instance Alternative Foo where
empty = undefined
```
Yields the following error message (I've tried GHC 8.10 through 9.8):
```
$ ghc-9.8.1 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:11:3: error: [GHC-87543]
Ambiguous occurrence ‘empty’.
It could refer to
either ‘Map.empty’,
imported qualified from ‘Data.Map’ at Bug.hs:5:1-32
(and originally defined in ‘Data.Map.Internal’),
or ‘Set.empty’,
imported qualified from ‘Data.Set’ at Bug.hs:6:1-32
(and originally defined in ‘Data.Set.Internal’).
|
11 | empty = undefined
| ^^^^^
```
This program _is_ invalid, but not for the reasons stated in this error message. `empty` isn't ambiguous at all. Rather, it's not in scope in the first place! The fix is to bring it into scope like so:
```diff
-import Control.Applicative (Alternative)
+import Control.Applicative (Alternative(empty))
```
The error message would have you believe that the problem is that GHC cannot pick between `Map.empty` and `Set.empty`. But this isn't the case at all, as the program would not be valid if you substituted either of these identifiers into the instance. For instance, if you wrote this:
```hs
instance Alternative Foo where
Map.empty = undefined
```
Then GHC would instead produce this error message:
```
$ ghc-9.8.1 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:11:3: error: [GHC-87543]
Ambiguous occurrence ‘Map.empty’.
It could refer to
either ‘Map.empty’,
imported qualified from ‘Data.Map’ at Bug.hs:5:1-32
(and originally defined in ‘Data.Map.Internal’),
or ‘Set.empty’,
imported qualified from ‘Data.Set’ at Bug.hs:6:1-32
(and originally defined in ‘Data.Set.Internal’).
|
11 | Map.empty = undefined
| ^^^^^^^^^
Bug.hs:11:3: error: [GHC-28329]
Qualified name in binding position: Map.empty
|
11 | Map.empty = undefined
| ^^^^^^^^^
```
It took several minutes of head-scratching to realize what the _actual_ issue was. It would be nice if GHC could tell me the actual problem (`empty` not being in scope) in the first place.https://gitlab.haskell.org/ghc/ghc/-/issues/24244Should NameSpace be abstract?2024-03-14T13:03:23ZZubinShould NameSpace be abstract?Projects outside of GHC, like [hiedb](https://github.com/wz1000/HieDb) and HLS, sometimes find it necessary to serialise GHC Names and OccNames independently of mechanism in GHC itself. For this, it is necessary to be able to construct a...Projects outside of GHC, like [hiedb](https://github.com/wz1000/HieDb) and HLS, sometimes find it necessary to serialise GHC Names and OccNames independently of mechanism in GHC itself. For this, it is necessary to be able to construct and inspect the `NameSpace` component. Currently they do this in an ad-hoc manner using the `isVarNameSpace`, `isDataNameSpace`... family of functions. It would be helpful if we could just pattern match on the constructors.
I don't quite understand what we gain from making `NameSpace` and abstract type. I propse that we export its constructors to allow tooling developers to inspect and construct `NameSpace`s freely.9.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/24109OccEnv should be deterministic2023-10-24T14:15:29ZSebastian GrafOccEnv should be deterministicWhile debugging a subtle unique mismatch error in !11470 that became visible in test `bkp15`, I became aware that `lookupGRE` returns a lot of non-deterministic lookup results without proper justification. E.g.,
```hs
-- | Lookup an ele...While debugging a subtle unique mismatch error in !11470 that became visible in test `bkp15`, I became aware that `lookupGRE` returns a lot of non-deterministic lookup results without proper justification. E.g.,
```hs
-- | Lookup an element in an 'OccEnv', ignoring 'NameSpace's entirely.
lookupOccEnv_AllNameSpaces :: OccEnv a -> OccName -> [a]
lookupOccEnv_AllNameSpaces (MkOccEnv as) (OccName _ s)
= case lookupFsEnv as s of
Nothing -> []
Just r -> nonDetEltsUFM r
-- | Look up all the record fields that match with the given 'FastString'
-- in an 'OccEnv'.
lookupFieldsOccEnv :: OccEnv a -> FastString -> [a]
lookupFieldsOccEnv (MkOccEnv as) fld =
case lookupFsEnv as fld of
Nothing -> []
Just flds -> nonDetEltsUFM $ filter_flds flds
-- NB: non-determinism is OK: in practice we will either end up resolving
-- to a single field or throwing an error.
where
filter_flds = filterUFM_Directly (\ uniq _ -> isFldNSUnique uniq)
```
The comment in `lookupFieldsOccEnv` is not quite the full story, even: Looking at its only use site in `GHC.Tc.Gen.Export.check_occs`, I see that the order becomes relevant in the generated error message. Now, codegen isn't really influenced by this non-determinism, but error messages will be affected, I think.
`lookupOccEnv_AllNamespaces` on the other hand doesn't even come with a warning in its haddock! It has transitive uses in
- `lookupImpOccEnv`
- `lookupGRE`
Non of which announce the non-determinism.
# Proposal
```diff
-newtype OccEnv a = MkOccEnv (FastStringEnv (UniqFM NameSpace a))
+newtype OccEnv a = MkOccEnv (FastStringEnv (UniqDFM NameSpace a))
```https://gitlab.haskell.org/ghc/ghc/-/issues/24070Unexported bindings can't be used on reload in GHCi when using `-fbyte-code ...2023-10-10T14:14:43ZZubinUnexported bindings can't be used on reload in GHCi when using `-fbyte-code -fprefer-byte-code -fwrite-interface -fbyte-code-and-object-code````haskell
-- A.hs
module A () where
double :: Int -> Int
double x = x + x
```
```bash
❯ ghci-9.6 A.hs -fbyte-code -fprefer-byte-code -fwrite-interface -fbyte-code-and-object-code
GHCi, version 9.6.3: https://www.haskell.org/ghc/ :? f...```haskell
-- A.hs
module A () where
double :: Int -> Int
double x = x + x
```
```bash
❯ ghci-9.6 A.hs -fbyte-code -fprefer-byte-code -fwrite-interface -fbyte-code-and-object-code
GHCi, version 9.6.3: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/zubin/dotfiles/.ghci
[1 of 1] Compiling A ( A.hs, interpreted )
Ok, one module loaded.
λ> double 3
6
it :: Int
λ>
Leaving GHCi.
```
This is fine, but running it again doesn't work
```bash
❯ ghci-9.6 A.hs -fbyte-code -fprefer-byte-code -fwrite-interface -fbyte-code-and-object-code
GHCi, version 9.6.3: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/zubin/dotfiles/.ghci
Ok, one module loaded.
λ> double 3
<interactive>:1:1: error: [GHC-88464]
Variable not in scope: double :: t0 -> t
```
They are present in `extra_decls` field of the Iface.ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24057Add `-fignore-export-list` flag for use in GHCi2024-01-24T13:37:44ZZubinAdd `-fignore-export-list` flag for use in GHCiCurrently GHCi uses the `mi_globals` field of `ModIface` to provide the following features:
1. Non exported names are visible and can be used from the repl
2. The import environment of loaded modules is replicated in the repl, so that i...Currently GHCi uses the `mi_globals` field of `ModIface` to provide the following features:
1. Non exported names are visible and can be used from the repl
2. The import environment of loaded modules is replicated in the repl, so that if you `import M` in a file and then load the file in GHCi, symbols from `M` will be available in the repl
Unfortunately using `mi_globals` for this can leak a lot of memory: #22832
Instead I propose to introduce a new flag `-fignore-export-list` that makes GHC behave as if the export list isn't present while compiling a module. This can be used by GHCi to provide feature 1.
For feature 2 I propose that we have special logic in GHCi to contruct an RdrEnv from the header of the currently loaded module(s).
This way, we can avoid keeping `mi_globals` around for all the modules in a big GHCi session with a lot of files, and instead only construct the `RdrEnv` for a module that is `:load`ed into the repl, from its header, avoiding keeping the `RdrEnv` around for its transitive dependencies.ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24035incorrect `-Wunused-imports` when module exports multiple records with the sa...2023-10-03T14:13:43ZMagnus Viernickelincorrect `-Wunused-imports` when module exports multiple records with the same accessor names## Summary
GHC emits unused imports warnings when the module that is imported from has `DuplicatRecordFields` activated and exports Records with same acessor fields
## Steps to reproduce
```hs
{-# LANGUAGE DuplicateRecordFields #-}
...## Summary
GHC emits unused imports warnings when the module that is imported from has `DuplicatRecordFields` activated and exports Records with same acessor fields
## Steps to reproduce
```hs
{-# LANGUAGE DuplicateRecordFields #-}
module A where
data R = MkR {ra :: Int, rb :: Bool}
data R' = MkR' {ra :: Int, rb :: Bool}
```
```hs
{-# LANGUAGE OverloadedRecordDot #-}
{-# OPTIONS_GHC -Wall #-}
module B where
import A (R (ra), rb) -- this line emits the warnings for `rb`
x :: R -> Bool
x a = a.rb
y :: R -> Int
y a = a.ra
```
## Expected behavior
No unused import warning
## Environment
* GHC version used: ghc 9.6.2
Optional:
* Operating System: NixOS 23.11
* System Architecture: x86_64-linuxsheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/24027TypeData constructor names confusion when checking exports2023-10-03T14:04:05ZGergő ÉrdiTypeData constructor names confusion when checking exportsGiven these two modules:
```haskell
module A(Foo(..)) where
data Foo = Foo1 | Foo2 | Foo3
```
```haskell
{-# LANGUAGE DataKinds, TypeData #-}
module B(Foo(Foo1, Foo2)) where
import qualified A
type data Foo = Foo1 | Foo2 | Foo3
```
...Given these two modules:
```haskell
module A(Foo(..)) where
data Foo = Foo1 | Foo2 | Foo3
```
```haskell
{-# LANGUAGE DataKinds, TypeData #-}
module B(Foo(Foo1, Foo2)) where
import qualified A
type data Foo = Foo1 | Foo2 | Foo3
```
There should be no confusion in what the `Foo1` and `Foo2` refers to in the export spec of `B`, since `A` is imported qualified. And yet as of b8ebf876d34e240413988d990e9208a12f9ca089 GHC produces the following error message:
```
input/type-data-export/B.hs:2:10: error: [GHC-88993]
• The type constructor ‘Foo’ is not the parent of the data constructor ‘Foo2’.
Data constructors can only be exported with their parent type constructor.
Parent: A.Foo
• In the export: Foo(Foo1, Foo2)
|
2 | module B(Foo(Foo1, Foo2)) where
| ^^^^^^^^^^^^^^^
input/type-data-export/B.hs:2:10: error: [GHC-88993]
• The type constructor ‘Foo’ is not the parent of the data constructor ‘Foo1’.
Data constructors can only be exported with their parent type constructor.
Parent: A.Foo
• In the export: Foo(Foo1, Foo2)
|
2 | module B(Foo(Foo1, Foo2)) where
| ^^^^^^^^^^^^^^^
```sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23992`$` converts ambiguous record update error to a warning2023-09-26T14:44:03ZEmeka Nkurumeh`$` converts ambiguous record update error to a warning## Summary
Inserting `$` between a function call and a record update can change ambiguous record update errors, into warnings. This behavior is specific to `$` since using `Data.Function.&` or aliasing `$` still produce error. As far as...## Summary
Inserting `$` between a function call and a record update can change ambiguous record update errors, into warnings. This behavior is specific to `$` since using `Data.Function.&` or aliasing `$` still produce error. As far as I can tell this seems to be a regression since before GHC 9.2.5, only type applications were able to change this error to a warning.
## Steps to reproduce
```haskell
{-# LANGUAGE DuplicateRecordFields #-}
data Foo1 = Foo1
{ foo :: Int
, bar :: Int
}
data Foo2 = Foo2
{ foo :: Int
, baz :: Int
}
setFoo :: Int -> Foo1 -> Foo1
setFoo x f = id f {foo = x}
```
GHC gives the following error:
```
Example.hs:14:17: error: [GHC-99339]
• Record update is ambiguous, and requires a type signature
• In the first argument of ‘id’, namely ‘f {foo = x}’
In the expression: id f {foo = x}
In an equation for ‘setFoo’: setFoo x f = id f {foo = x}
|
14 | setFoo x f = id f {foo = x}
|
```
If we insert a `$` into `setFoo` as so: `setFoo x f = id $ f {foo = x}`, we get a warning instead:
```
Example.hs:14:22: warning: [GHC-02256] [-Wambiguous-fields]
The record update f {foo = x} with type Foo1 is ambiguous.
This will not be supported by -XDuplicateRecordFields in future releases of GHC.
|
14 | setFoo x f = id $ f {foo = x}
|
```
## Expected behavior
Return the same error as if there were no `$`.
## Environment
* GHC version used: 9.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/23982Better error for unimported constructor (GHC-31891)2024-01-26T10:58:24ZTeo CamarasuBetter error for unimported constructor (GHC-31891)## Summary
When we use an un-imported constructor when its type is in-scope and has the same name, we get an error that warns us that we are using a type instead of a term. Whenever I get this error it's simply because I've forgotten to...## Summary
When we use an un-imported constructor when its type is in-scope and has the same name, we get an error that warns us that we are using a type instead of a term. Whenever I get this error it's simply because I've forgotten to import the constructor. That's fine for me, but I think this would likely trip up a beginner.
It would be better if GHC suggested that we import the constructor.
## Steps to reproduce
```
module A where
data A = A
```
```
module B where
import A (A)
test = A
```
Then compile it using `ghc A.hs B.hs`.
And you will get this error:
```
[1 of 2] Compiling A ( A.hs, A.o )
[2 of 2] Compiling B ( B.hs, B.o )
B.hs:5:8: error: [GHC-31891]
• Illegal term-level use of the type constructor or class ‘A’
• imported from ‘A’ at B.hs:3:11
(and originally defined at A.hs:3:1-10)
• Add ‘A’ to the import list in the import of ‘A’ (at B.hs:3:1-12).
• In the expression: A
In an equation for ‘test’: test = A
|
5 | test = A
|
```
## Expected behavior
Suggest that the user imports this type, compare if we don't import the type at all:
```
[2 of 2] Compiling B ( B.hs, B.o )
B.hs:5:8: error: [GHC-88464]
Data constructor not in scope: A
Suggested fix:
Add ‘A’ to the import list in the import of ‘A’ (at B.hs:3:1-11).
|
5 | test = A
|
```
## Environment
* GHC version used: GHC-9.4.7, I think also happens with HEADsheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23963Cannot disambiguate duplicate pattern synonym record fields in exports2023-10-06T13:18:39ZAdam GundryCannot disambiguate duplicate pattern synonym record fields in exportsConsider the following module:
```hs
{-# LANGUAGE GHC2021 #-}
{-# LANGUAGE DuplicateRecordFields #-}
{-# LANGUAGE PatternSynonyms #-}
module RecPatSyn (B(B, x)) where
data A = MkA {x_ :: Int}
data B = MkB {x_ :: Int}
pattern A :: Int...Consider the following module:
```hs
{-# LANGUAGE GHC2021 #-}
{-# LANGUAGE DuplicateRecordFields #-}
{-# LANGUAGE PatternSynonyms #-}
module RecPatSyn (B(B, x)) where
data A = MkA {x_ :: Int}
data B = MkB {x_ :: Int}
pattern A :: Int -> A
pattern A{x} <- MkA x
pattern B :: Int -> B
pattern B{x} <- MkB x
```
There is no way to express the fact that in the export list we mean the `x` originating from pattern synonym `B`. Hence this is rejected with an ambiguous occurrence error:
```
RecPatSyn.hs:5:19: error: [GHC-66025]
• Pattern synonyms can only be bundled with matching type constructors
Couldn't match expected type of ‘B’ with actual type of ‘A’
• In the pattern synonym record selector: x
In the export: B(B, x)
|
5 | module RecPatSyn (B(B, x)) where
| ^^^^^^^
RecPatSyn.hs:5:19: error: [GHC-87543]
• Ambiguous occurrence ‘x’.
It could refer to
either the field ‘x’ of pattern synonym ‘A’,
defined at RecPatSyn.hs:12:11,
or the field ‘x’ of pattern synonym ‘B’,
defined at RecPatSyn.hs:15:11.
• In the export: B(B, x)
|
5 | module RecPatSyn (B(B, x)) where
| ^^^^^^^
```
The "Pattern synonyms can only be bundled with matching type constructors" bit of the error seems to be bogus. Presumably the ambiguous identifier is "resolved" to the first option to allow type-checking to continue. But it leads to the awkward situation where the renamer considers it ambiguous which `x` is meant, yet the type-checker apparently "knows" that `x` cannot come from `A`.
It's not obvious to me how we could do better here, but it's an awkward corner of the `PatternSynonyms`/`DuplicateRecordFields` interaction that I wanted to record.
This was originally reported at https://discourse.haskell.org/t/how-to-export-record-pattern-synonym-duplicate-field-names-in-the-same-module/7594.https://gitlab.haskell.org/ghc/ghc/-/issues/23888Qualified Do: Non-imported module leads to inaccurate error messages2023-08-29T15:45:35ZHannes SiebenhandlQualified Do: Non-imported module leads to inaccurate error messages## Summary
When using `QualifiedDo`, `Ix.do` leads to inaccurate error messages when no module named `Ix` is imported.
Example:
## Steps to reproduce
```haskell
{-# LANGUAGE QualifiedDo #-}
test = Ix.do
x <- someOperation "Test"
...## Summary
When using `QualifiedDo`, `Ix.do` leads to inaccurate error messages when no module named `Ix` is imported.
Example:
## Steps to reproduce
```haskell
{-# LANGUAGE QualifiedDo #-}
test = Ix.do
x <- someOperation "Test"
pure x
someOperation = undefined
```
![image](/uploads/b1ffc28e2e7c34235cd223f4392149dd/image.png)
```
Not in scope: ‘Ix.>>=’
NB: no module named ‘Ix’ is imported.
```
## Expected behavior
Either the whole do-block or `Ix.do` should have an error source span noting that `Ix` is not imported.
## Environment
* GHC version used: 9.6.2 and 9.4.6
Optional:
* Operating System and System Architecture: Linux hugin 6.4.10-arch1-1 \#1 SMP PREEMPT_DYNAMICHannes SiebenhandlHannes Siebenhandlhttps://gitlab.haskell.org/ghc/ghc/-/issues/23781Implement namespace-specified imports and fix ExplicitNamespaces2023-08-08T15:06:40ZAdam GundryImplement namespace-specified imports and fix ExplicitNamespacesThe GHC Steering Committee has accepted [proposal 581: namespace-specified imports](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0581-namespace-specified-imports.rst). This tightens up the specification of `Explic...The GHC Steering Committee has accepted [proposal 581: namespace-specified imports](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0581-namespace-specified-imports.rst). This tightens up the specification of `ExplicitNamespaces`, allows `data` as a namespace specifier instead of `pattern`, and permits imports to use `type ..` and `data ..` to refer to all items in the corresponding namespaces.sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23764Wrong implicit quantification order with LinearTypes2023-08-08T15:17:09ZAndrei BorzenkovWrong implicit quantification order with LinearTypes## Summary
GHC doesn't follow left-to-right order in implicit quantification of parametric by linearity arrow
## Steps to reproduce
```haskell
ghci> :set -XLinearTypes
ghci> :set -fprint-explicit-foralls
ghci> f :: a %p -> b; f = f
...## Summary
GHC doesn't follow left-to-right order in implicit quantification of parametric by linearity arrow
## Steps to reproduce
```haskell
ghci> :set -XLinearTypes
ghci> :set -fprint-explicit-foralls
ghci> f :: a %p -> b; f = f
ghci> :t f
f :: forall a b (p :: Multiplicity). a %p -> b
```
## Expected behavior
I expect implicit quantification to follow left-to-right order, so `f` should have type `f :: forall a (p :: Multiplicity) b. a %p -> b`
## Environment
* GHC version used: [9.0 .. HEAD]https://gitlab.haskell.org/ghc/ghc/-/issues/23706Shadowing selectors are not warned about / Warn about shadowing top-level names.2023-07-25T14:45:17ZOleg GrenrusShadowing selectors are not warned about / Warn about shadowing top-level names.An example:
```haskell
module Shadow (Foo (..)) where
data Foo = Foo { id :: Int, const :: Char }
```
```
ghc-9.6.2 -fforce-recomp -Weverything -Wno-missing-safe-haskell-mode -Wno-implicit-prelude -Wno-missing-kind-signatures -Wno-uns...An example:
```haskell
module Shadow (Foo (..)) where
data Foo = Foo { id :: Int, const :: Char }
```
```
ghc-9.6.2 -fforce-recomp -Weverything -Wno-missing-safe-haskell-mode -Wno-implicit-prelude -Wno-missing-kind-signatures -Wno-unsafe Shadow.hs
```
compiles the module without any warnings.
However, `id` is obviously shadowing (in fact clashing) with imported name.
---
I guess it's somewhat consistent with the fact that in "explicit" version
```haskell
{-# LANGUAGE NoFieldSelectors #-}
module ShadowNoSelectors (Foo (..), ShadowNoSelectors.id) where
data Foo = Foo { id :: Int, const :: Char }
id :: Foo -> Int
id (Foo x _) = x
```
the ambiguity error will cause only on export. With no export list (i.e. `module ShadowNoSelectors where`) there are also no warnings.
So I ask for a warning which warns when a module **top-level definition** has the same name as some imported binding.
---
Note: non-top level definitions **are** warned about:
```haskell
module NonTop where
foo :: Bool
foo = id True where id = not
```
```
NonTop.hs:4:21: warning: [GHC-63397] [-Wname-shadowing]
This binding for ‘id’ shadows the existing binding
imported from ‘Prelude’ at NonTop.hs:1:8-13
(and originally defined in ‘GHC.Base’)
|
4 | foo = id True where id = not
| ^^
```
which itself is IMHO way less dangerous as the binding is local, and cannot cause problems elsewhere. On the other hand exported top-level ambiguous bindings may cause problems elsewhere (as e.g. defined `id` field name in a module without `NoFieldSelectors`).https://gitlab.haskell.org/ghc/ghc/-/issues/23614Give spelling suggestions in :info2023-08-24T19:14:22ZKrzysztof GogolewskiGive spelling suggestions in :info`:i` could give the same suggestions as `:t`:
```
ghci> :t travers
<interactive>:1:1: error: [GHC-88464]
Variable not in scope: travers
Suggested fix: Perhaps use ‘traverse’ (imported from Prelude)
ghci> :i travers
<interactiv...`:i` could give the same suggestions as `:t`:
```
ghci> :t travers
<interactive>:1:1: error: [GHC-88464]
Variable not in scope: travers
Suggested fix: Perhaps use ‘traverse’ (imported from Prelude)
ghci> :i travers
<interactive>:1:1: error: [GHC-76037] Not in scope: ‘travers’
ghci>
```https://gitlab.haskell.org/ghc/ghc/-/issues/23588Missing redundant import depending on import order and reexported symbols2023-07-04T14:57:54ZGuillaume BouchardMissing redundant import depending on import order and reexported symbols## Summary
The `unused-import` warning may appear or not depending on the order of the imports and reexported symbols.
## Steps to reproduce
module `A.hs`:
```haskell
module A (foo, bar) where
foo = 10
bar = 20
```
module `B.hs`:
...## Summary
The `unused-import` warning may appear or not depending on the order of the imports and reexported symbols.
## Steps to reproduce
module `A.hs`:
```haskell
module A (foo, bar) where
foo = 10
bar = 20
```
module `B.hs`:
```haskell
module B (foo) where
import A
```
module `C.hs`:
```haskell
{-# OPTIONS -Wall #-}
module C where
import A
import B
main :: IO ()
main = do
print foo
print bar
```
This leads to a warning when compiling `C.hs`:
```
C.hs:5:1: warning: [-Wunused-imports]
The import of ‘B’ is redundant
except perhaps to import instances from ‘B’
To import instances alone, use: import B()
|
5 | import B
| ^^^^^^^^
```
However, if `C.hs` is instead:
```haskell
{-# OPTIONS -Wall #-}
module C where
import B
import A
main :: IO ()
main = do
print foo
print bar
```
(Note that `import B` and `import A` have been swapped).
With this file, the warning does not appear.
## Expected behavior
I would like the warning to not depend on the order of the imports and to be always there.
This surprising behavior have multiples impacts for me:
- After applying a formatter which changed the import order, new warnings may appears, which can break the build (if `-Werror`).
- Not having this warning is a missed opportunity to reduce dependencies footprint.
## Environment
* GHC version used: 9.6.1
Optional:
* Operating System:
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/23377Refactor thRdrNameGuesses to account for record field namespaces2024-01-09T16:01:19Zsheafsam.derbyshire@gmail.comRefactor thRdrNameGuesses to account for record field namespacesCurrently, `thRdrNameGuesses` returns a list of possible `RdrName`s that a `TH.Name` could refer to. However, now that there are an infinite number of possible namespaces with the introduction of record field namespaces, we should instea...Currently, `thRdrNameGuesses` returns a list of possible `RdrName`s that a `TH.Name` could refer to. However, now that there are an infinite number of possible namespaces with the introduction of record field namespaces, we should instead return a predicate that tells us which namespaces we should be allowed to look into when looking it up (see `lookupThName_maybe` and `thNameToGhcNameIO`). This would allow us to be a bit more robust in cases like #23376 in which one looks up a record field using the variable namespace instead of the record field namespace.sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23032Disambiguating record updates in the renamer using as-patterns2023-06-05T12:06:39Zsheafsam.derbyshire@gmail.comDisambiguating record updates in the renamer using as-patternsI think the following could reasonably be expected to work:
```haskell
{-# LANGUAGE DuplicateRecordFields #-}
module M where
data A a = MkA { fld :: a }
data B b = MkB { fld :: b }
foo x r@(MkA{}) = r { fld = x }
```
When renaming the...I think the following could reasonably be expected to work:
```haskell
{-# LANGUAGE DuplicateRecordFields #-}
module M where
data A a = MkA { fld :: a }
data B b = MkB { fld :: b }
foo x r@(MkA{}) = r { fld = x }
```
When renaming the record update on the RHS of `foo`, the renamer would see `r`, and look up in some environment to see it is associated with the pattern `MkA{}` which disambiguates which record field `fld` refers to.
Currently `rnPat` doesn't create any kind of environment to keep track of the connection in an as-pattern:
```haskell
rnPatAndThen mk (AsPat _ rdr at pat)
= do { new_name <- newPatLName mk rdr
; pat' <- rnLPatAndThen mk pat
; return (AsPat noExtField new_name at pat') }
```
whereas the typechecker does:
```haskell
tc_pat pat_ty penv ps_pat thing_inside = case ps_pat of
...
AsPat x (L nm_loc name) at pat -> do
{ ...
; (wrap, bndr_id) <- setSrcSpanA nm_loc (tcPatBndr penv name pat_ty)
; (pat', res) <- tcExtendIdEnv1 name bndr_id $
tc_lpat (pat_ty `scaledSet`(mkCheckExpType $ idType bndr_id))
penv pat thing_inside
; ... }
```
I think this would be a rather satisfying way to disambiguate record updates, although one shortcoming is that it does not handle sum types very well, as one has to have a separate case for each constructor. We would want something like or-patterns:
```haskell
data C c = MkC1 { fld1, fld2, fld3 :: c } | MkC2 { fld1, fld2 :: c }
data D d = MkD1 { fld1, fld2 :: d }
-- OK, but requires listing all the constructors
bar1 c1 c2 r@(MkC1{} or MkC2{}) = r { fld1 = c1, fld2 = c2 }
-- Even better, just mention a single constructor!
bar2 c1 c2 r@(MkC1{} or _) = r { fld1 = c1, fld2 = c2 }
```https://gitlab.haskell.org/ghc/ghc/-/issues/23020Panic on wrong imports with TypeData2023-02-27T23:54:12ZKrzysztof GogolewskiPanic on wrong imports with TypeDataGiven
```haskell
{-# LANGUAGE TypeData #-}
module TD where
type data A = X | Y | Z
```
This is accepted:
```haskell
module TD2 where
import TD (Y(X))
```
It shouldn't be: `X` is not a constructor of `Y`. Adding one more
```haskell...Given
```haskell
{-# LANGUAGE TypeData #-}
module TD where
type data A = X | Y | Z
```
This is accepted:
```haskell
module TD2 where
import TD (Y(X))
```
It shouldn't be: `X` is not a constructor of `Y`. Adding one more
```haskell
module TD2 where
import TD (Y(X), Z(X))
```
causes a panic:
```
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.7.20230218:
hasParent
parent:Y parent:Z
```Aaron AllenAaron Allen