New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug with first-class modules and includes #6262
Comments
Comment author: @lpw25 This bug may seem harmless, but it causes a soundness bug in 4.01.0:
Since r14305 this soundness bug no longer exists because the exhaustivity checker now seems to always assumes that package types may be compatible, so the bug is probably "harmless" again. |
Comment author: @lpw25 In general, first-class modules do not interact well with module inclusion because they ignore module type aliases. Assuming that making first-class modules work based on the structures of modules rather than their paths is too much work, I think that the best solution to this problem is to make first-class modules take module type aliases into account. So given:
|
Comment author: @alainfrisch I agree with your latest note and I attach a patch attempting to take module type aliases into account for the equality of package types. |
Comment author: @alainfrisch Commit to trunk, rev 14342. Thanks! |
Original bug ID: 6262
Reporter: @lpw25
Assigned to: @alainfrisch
Status: closed (set by @xavierleroy on 2015-12-11T18:25:26Z)
Resolution: fixed
Priority: normal
Severity: minor
Category: typing
Monitored by: @hcarty
Bug description
There is a bug in the interaction between first-class modules and includes:
This says that
Y.t
is equal toX.t
, however the representations of these types are not equivalent because(module X.S)
is not equal to(module Y.S)
.File attachments
The text was updated successfully, but these errors were encountered: