# .cmt/.cmti question

**URL:** <https://discuss.ocaml.org/t/cmt-cmti-question/5308>\
**Category:** Learning\
**Created:** [March 13, 2020, 6:31pm UTC](https://discuss.ocaml.org/t/cmt-cmti-question/5308 "2020-03-13T18:31:49Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![progman](https://avatars.discourse-cdn.com/v4/letter/p/8797f3/32.png) [@progman](https://discuss.ocaml.org/u/progman)\
**Post date:** [March 13, 2020, 6:31pm UTC](https://discuss.ocaml.org/t/cmt-cmti-question/5308/1 "2020-03-13T18:31:49Z")

</div>

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:

1. 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:

1. 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,

1. 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.

---

<div class="post-metadata">

**Author:** ![octachron](https://avatars.discourse-cdn.com/v4/letter/o/49beb7/32.png) [@octachron](https://discuss.ocaml.org/u/octachron)\
**Post date:** [March 14, 2020, 2:53pm UTC](https://discuss.ocaml.org/t/cmt-cmti-question/5308/2 "2020-03-14T14:53:46Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![progman](https://avatars.discourse-cdn.com/v4/letter/p/8797f3/32.png) [@progman](https://discuss.ocaml.org/u/progman)\
**Post date:** [March 15, 2020, 8:21am UTC](https://discuss.ocaml.org/t/cmt-cmti-question/5308/3 "2020-03-15T08:21:16Z")

</div>

so I am likely seeing false positives. blast!  
I tried :

```auto
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!

---

<div class="post-metadata">

**Author:** ![octachron](https://avatars.discourse-cdn.com/v4/letter/o/49beb7/32.png) [@octachron](https://discuss.ocaml.org/u/octachron)\
**Post date:** [March 15, 2020, 9:33am UTC](https://discuss.ocaml.org/t/cmt-cmti-question/5308/4 "2020-03-15T09:33:09Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![progman](https://avatars.discourse-cdn.com/v4/letter/p/8797f3/32.png) [@progman](https://discuss.ocaml.org/u/progman)\
**Post date:** [March 15, 2020, 11:21am UTC](https://discuss.ocaml.org/t/cmt-cmti-question/5308/5 "2020-03-15T11:21:12Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![octachron](https://avatars.discourse-cdn.com/v4/letter/o/49beb7/32.png) [@octachron](https://discuss.ocaml.org/u/octachron)\
**Post date:** [March 15, 2020, 11:38am UTC](https://discuss.ocaml.org/t/cmt-cmti-question/5308/6 "2020-03-15T11:38:01Z")

</div>

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](https://github.com/ocaml/ocaml/blob/trunk/typing/env.mli#L234)

---

<div class="post-metadata">

**Author:** ![progman](https://avatars.discourse-cdn.com/v4/letter/p/8797f3/32.png) [@progman](https://discuss.ocaml.org/u/progman)\
**Post date:** [March 15, 2020, 12:47pm UTC](https://discuss.ocaml.org/t/cmt-cmti-question/5308/7 "2020-03-15T12:47:15Z")

</div>

find\_type\_by\_name ~=~ lookup\_type \> 4.10 !

and once the path head was taken out it works like a charm.  
thank you!