Format_doc: preserve the type of Foo.report_error, add Foo.report_error_doc#13311
Format_doc: preserve the type of Foo.report_error, add Foo.report_error_doc#13311Octachron merged 3 commits intoocaml:trunkfrom
Conversation
|
One thing that makes me think is that there are other source of breakage introduced in #13169 than the change of type to those functions, see for example janestreet/base#166 : #13169 changes the type of other printer-ish types in compiler-libs, that may affect even more downstream users: github search for Printtyp.signature. I don't know if I want to apply the same approach to those changes as well, and whether it is reasonable to do this consistently. Probably? |
debugger/eval.mli
Outdated
| exception Error of error | ||
|
|
||
| val report_error: formatter -> error -> unit | ||
|
|
| type 'a format_printer = Format.formatter -> 'a -> unit | ||
| val compat: 'a printer -> 'a format_printer | ||
| val compat1: ('p1 -> 'a printer) -> ('p1 -> 'a format_printer) | ||
| val compat2: ('p1 -> 'p2 -> 'a printer) -> ('p1 -> 'p2 -> 'a format_printer) |
There was a problem hiding this comment.
If you want to have various compat for different arity, I have seen a case of compat0: (Format_doc.formatter -> unit) -> Format.formatter -> unit in the wild
Octachron
left a comment
There was a problem hiding this comment.
The change is clearly correct, and I can grumpily agree that error reporters are part of the more public part of compiler-libs.
|
I implemented |
…or_doc The introduction of Format_doc changed the type of various 'reprot_error' functions in the compiler codebase. But this breaks user code. An alternative proposed here is to keep 'report_error' at the same type as before and introduce 'report_error_doc' in addition.
The introduction of Format_doc in #13169 changed the type of various 'report_error' functions in the compiler codebase. But this breaks user code. An alternative proposed here is to keep 'report_error' at the same type as before and introduce 'report_error_doc' in addition.
(I had a discussion with @Octachron this morning on how long it would take to write this PR. For now my current time is 40mn.)