I recently tried to make use of the typedtree info in a .cmt file and found that the stored ‘initial’ environment yielded to look-ups of type declarations made in the associated source file.
my first question is:
- in what sense is cmt_initial_env initial, and not named final_env?
when an interface file is used and the type declarations are abstract, the look-up
of such declarations yields abstracted results.
I have tried chasing the code of [Includemod.compunit] as I imagine somewhere there the said environment is being side-effected into an abstract version.
with no luck there I’d really like to know:
- how is the final environment saved to the .cmt being transformed with abstracted type declarations? (indeed it appears to effect environments stored in the nodes of the typedtree too)
given that when there is an interface file, with -bin-annot a .cmti file created,
- why is it that the abstracted environment is not confined to there rather than constraining the .cmt too?
it seems odd to me to make available the typedtree (in the .cmt) only to then restrict the information embedded within it.
my own intended use for it was debugging.
The initial environment is really just the initial environment and does not contain any information about the items in the implementation. From your description, it sounds like you are inavertidly reading from the cmi file.
so I am likely seeing false positives. blast!
I tried :
match cmt.cmt_annots with
| Implementation s ->
let env = Envaux.env_of_only_summary s.str_final_env in
let decl = Env.(without_cmis (find_type p) env)) in
...
...
on the assumption that later structure items would see earlier ones in their environment
but that didn’t work.
Is it then the case that the module’s declarations are not to be found in any Env.t saved in the .cmt, and if I want them I need to recreate them from the typedtree?
thanks!
The final structure environment should know about all items of the structure. Are you maybe using an invalid longident like Lident "M.t" for the lookup? Or if you are using find_type and not find_type_by_name, how did you get the path?
find_type_by_name - where’s that?
I’m effectively using
Pdot(Pident(Ident.create_persistent “M”, “t”))
and a declaration is found via find_type but
decl.type_loc.loc_start.pos_fname
shows m.mli !
is it possible the cmi is still consulted in spite of Env.without_cmis?
You cannot create paths by yourself, they are essentially the compiled (resolved and unique) variants of Longident.t.
If you are creating a path with a persistent ident, you are essentially asking for the compilation unit m.mli. So the lookup try to read the m.cmi file because it is the path that you asked; and it fails because you are forbidding Env to read cmis with without_cmis.
The functions for finding values by longident are here: https://github.com/ocaml/ocaml/blob/trunk/typing/env.mli#L234
find_type_by_name ~=~ lookup_type > 4.10 !
and once the path head was taken out it works like a charm.
thank you!