Skip to content
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

Failing component lookup #6651

Closed
vicuna opened this issue Nov 9, 2014 · 4 comments
Closed

Failing component lookup #6651

vicuna opened this issue Nov 9, 2014 · 4 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Nov 9, 2014

Original bug ID: 6651
Reporter: @lpw25
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2017-09-24T15:32:50Z)
Resolution: fixed
Priority: normal
Severity: minor
Fixed in version: 4.03.0+dev / +beta1
Category: typing
Related to: #2388 #7192
Monitored by: @gasche @hcarty

Bug description

The following code works:

module type S = sig
  module type T
  module X : T
end

module M = struct
  module type T = sig type t end
  module X = struct type t = int end
end

module F (X : S) = X.X

type t = F(M).t

However, if we change the order of the definitions of F and M:

module type S = sig
  module type T
  module X : T
end

module F (X : S) = X.X

module M = struct
  module type T = sig type t end
  module X = struct type t = int end
end

type t = F(M).t

then it fails:

$ ocamlc -c test.ml
File "test.ml", line 13, characters 13-19:
Error: Unbound type constructor F(M).t

This is because components_of_module_maker uses the environment from the definition of F to perform scrape_alias, so it does not see the definition of M if it is defined after F.

File attachments

@vicuna
Copy link
Author

vicuna commented Nov 10, 2014

Comment author: @garrigue

Just to clarify: the problem is not new; you get exactly the same error message with 3.08 for instance.
Will look into it.

@vicuna
Copy link
Author

vicuna commented Nov 10, 2014

Comment author: @garrigue

The env.diff patch solves this problem by replacing the environment inherited from the functor by the current one.
The test suite goes through, so this does not seem too bad.
However, this means that we would no longer be using the fcomp_env field, and this field comes with the comment "Environment in which the result signature makes sense". This seems to imply that without it it does not make sense, so maybe we need a specialist to check this.

@vicuna
Copy link
Author

vicuna commented Nov 12, 2014

Comment author: @garrigue

Updated env.diff, as it was breaking #2388.
The trick seems to do all the substitutions eagerly...

@vicuna
Copy link
Author

vicuna commented Nov 12, 2014

Comment author: @garrigue

Fixed in trunk at revision 15576.
However, I'm not 100% sure so need to check more programs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants