-
Notifications
You must be signed in to change notification settings - Fork 10
Check name visibility before attempting derivation #267
Copy link
Copy link
Open
Labels
derive: entryIssue on the derivation function facing to the end-userIssue on the derivation function facing to the end-userderive: infrastructureIssue around derivation, but not directly inIssue around derivation, but not directly inpart: derivationRelated to automated derivation of generatorsRelated to automated derivation of generatorsstatus: feature requestRequest for new functionality or improvementRequest for new functionality or improvement
Metadata
Metadata
Assignees
Labels
derive: entryIssue on the derivation function facing to the end-userIssue on the derivation function facing to the end-userderive: infrastructureIssue around derivation, but not directly inIssue around derivation, but not directly inpart: derivationRelated to automated derivation of generatorsRelated to automated derivation of generatorsstatus: feature requestRequest for new functionality or improvementRequest for new functionality or improvement
Consider the following module:
Suppose we want to derive a generator for the type
B. It's common to placederiveGenin a separate module. Unfortunately, this isn't possible in the example above becauseAis private. However, deptycheck does not correctly verify whether the name is available in the current context, so it proceeds to derive the generator anyway. After the (potentially lengthy) derivation, the elaborator fails with an error like:Name BlahBlahBlah.A is private.In such cases, it's likely the programmer simply forgot to add
public exportto the definition ofA. I suggest adding a proper check for name visibility before running the derivation. This would help catch such errors earlier and save a significant amount of time.