Florian Angeletti

The issue is due to opam sandboxing that blocks the downloading of the vulkan spec. For proper release, my idea was to distribute a fixed version of the vulkan xml...

Yep, I fell to the hubris of not checking the rebasing, this should be fixed now.

@Julow , do you wish to clean the history in order to preserve the individual message commits? Otherwise, I would squash the PR and merge the message commits.

Having links to examples and explanations in the manual is part of the longer plan. In particular, it would be easier to write examples and explanations for error messages once...

@dbuenzli The set of errors might evolve, for instance one error (`Tyco001`) might be split into two more specific errors (`Tyco015` and `Tyco016`). In this case, the old error identifier...

For another data point, it seems that Haskell is also moving in this direction: https://errors.haskell.org .

In term of dangling pointers, an interesting data point is that some error messages already point towards sections of the manual. However, since the manual is part of the compiler...

Another point that might be worth investigating is the integration with the functor unit RFC #11 . It seems that functor units would benefit from the possibility of communicating information...

Another data point: we already have header attributes for alerts (that I had forgotten). For instance, with ```ocaml (* a.mli *) [@@@alert Scylla] module M: sig [@@@alert Charibdys] end ```...

My main concern with `[@@@@ ...]` is that it begs the question of where do we stop, will we one day need `[@@@@@ ... ]` or `[@@@@@@ ...]` attributes? Maybe...