Read annotation in doc comment for exception about reanalyze

[cristianoc]

@Et7f3 one issue with doc comments is how to read them from libraries.
In the case of bucklescript, libraries are in a conventional place.
But in the case of native, libraries are wherever the build system looks for them (dune, or dune + esy), and it would be complex to replicate the same logic here.

What is definitely doable, is to do a one-off compilation of a library to extract the annotations, then use that to populate the tables vendored with he analysis.

[Et7f3]

one issue with doc comments is how to read them from libraries.

# (*comment*);;
# (**comment*);;
Ptop_def
  []
Ptop_def
  [
    structure_item (//toplevel//[1,0+0]..[1,0+12])
      Pstr_attribute "ocaml.text"
      [
        structure_item (//toplevel//[1,0+0]..[1,0+12])
          Pstr_eval
          expression (//toplevel//[1,0+0]..[1,0+12])
            Pexp_constant PConst_string("comment",None)
      ]
  ]

We can see that doc comment are preserved in the ast.

if comment are in interface file: then their is a .cmti/.cmi next to the implementation corresponding .cmt/.cmo.

it would be complex to replicate the same logic here.

So the logic is quite simple (remove the 'o' if it is last char and add 'i')

[cristianoc]

I think what's possible is a bootstrapping process, where doc comments can be used as a starting point. However, some manual tweaking has already been necessary:

    ("blit_string", [invalidArgument]),
    // ("concat", [invalidArgument]), if longer than {!Sys.max_string_length}
    // ("cat", [invalidArgument]), if longer than {!Sys.max_string_length}
    // ("escaped", [invalidArgument]), if longer than {!Sys.max_string_length}
    ("index", [notFound]),

where the commented-out functions would lead to mostly noise.