GitLab

This commit

commit 96621b1b4979f449e873513e9de8d806257c9493
    Associate pattern synonyms with types in module exports

added PatternSynonym to RdrName.Parent. That's a pretty heavy hammer. It forces us to add IsPatSyn to AvailInfo, including binary serialisation etc.

And I think it's needed in precisely one place, namely RnNames.findPatSyns. Right?

The caller of findPatSyns and the associated lookupChildren is jolly obscure and I don't fully understand it. I **think** the issue is this:

• I want to allow an export item T( K ), where K is a pattern synonym, even though it's not really (yet) associated with T.

I think the goal of this code was to reject the K if it's a data constructor.

But we also have a **further** check in tcExports to check that K has the right type.

Surely it'd be better to nuke this PatternSynonym and IsPatSyn stuff? Just useisDataOcc in the export lookup part. Then the tcExport check will object if you write an export item like Either( Just ).

Fewer moving parts!

Matthew, does this make sense? Might you look at it?

Trac metadata

Trac field	Value
Version	7.10.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture