Repository navigation
[minor] a -dmatchcomp for matching compiler debug output - #13425
Conversation
Note: -dmatchcomp does not behave like most other -dfoo options, because it shows course-of-compilation debug output instead of printing an intermediate representation of a compilation pass -- there are no separate intermediate representations for pattern-matching compilation, unfortunately. In particular, with the current implementation, -dmatchcomp does not respect the -dump-into-* parameters, it always print to debug output. Fixing this would be nice, but it requires cumbersome implementation work, because the matching.ml codebase is not parametrized over a debug channel. If someone wanted to tackle this, we would suggest the following route: - refactor Translcore to turn the ~scopes parameter into a more generic ~ctx parameter, a record with a `scopes`field - same thing with Translmod - add a `ppf_dump` field to this compilation context - add a `ctx` parameter (at a different type) to all Matching functions as well, and pass the `ppf_dump` alongside it - pass the context to the `debugf` calls
|
Ah, also: the debug output looks like garbage, and in particular it uses Format but seems to suffer from some pretty-printing bugs, where things are not shown as intended. This is fine: having this semi-broken output is much better than not having it. I try to fix the formatting sometimes, and usually give up because I don't know how to do it and it's not worth the time. |
lthls
left a comment
lthls
left a comment
There was a problem hiding this comment.
I'm fine with this PR.
In my experience it can also be useful to add support for passing this kind of flag through the OCAMLPARAM variable; it allows for debugging programs with complex build systems without patching this system (I have used this feature on the testsuite in a few cases).
The code to modify is in the file driver/compenv.ml, if you agree it's worth doing here.
|
@lthls There is already |
I would be fine with either solution. If I implemented it, I would probably go with the first solution. If you end up implementing |
|
I propose the |
3 participants
In the course of working on the Pattern-Matching Bug, I frequently needed to enable the matching compiler debug output to understand what was going on. Currently the way to do this is not very nice, one has to modify lambda/matching.ml to turn
let dbg = falseintolet dbg = true, and the resulting compiler produces a ton of debug output when building itself.This PR adds a
-dmatchcompoption to show the matching compilation debug output. This will make the pattern-matching compiler easier to observe and debug. The change is minimal, designed to be useful for compiler hacking only.Note: -dmatchcomp does not behave like most other -dfoo options,
because it shows course-of-compilation debug output instead of
printing an intermediate representation of a compilation pass -- there
are no separate intermediate representations for pattern-matching
compilation, unfortunately.
In particular, with the current implementation, -dmatchcomp does not
respect the -dump-into-* parameters, it always print to debug
output. Fixing this would be nice, but it requires cumbersome
implementation work, because the matching.ml codebase is not
parametrized over a debug channel.
If someone wanted to tackle this, I would suggest the following route:
generic ~ctx parameter, a record with a
scopesfieldppf_dumpfield to this compilation contextctxparameter (at a different type) to all Matchingfunctions as well, and pass the
ppf_dumpalongside itdebugfcallsThis is left outside the scope of the current PR.