Support `debuginfo` context option in IRShow for `IRCode`/`IncrementalCompact`

[serenity4]

This allows us to get complete source information during printing for IRCode and IncrementalCompact, same as we do by default with CodeInfo.

The user previously had to do:

Compiler.IRShow.show_ir(stdout, ir, Compiler.IRShow.default_config(ir; verbose_linetable=true))

and now, they only need to do:

show(IOContext(stdout, :debuginfo => :source), ir)

[Keno]

show(IOContext(stdout, :verbose_linetable => true), ir)

Or put it in the their global repl iocontext if they want it always and to apply to e.g. display.

[topolarity]

What do you think about debuginfo = :source (matching what code_typed et al accept), instead of verbose_linetable = true?

I would expect the latter to print a representation of the linetable itself, so it's a bit of a misnomer

[serenity4]

I agree that the current naming is not great. If we go with debuginfo = :source for the case verbose_linetable === true, the case verbose_linetable === false could be defined as debuginfo = :inline (or debuginfo = :source_inline).

[topolarity]

That sounds all right to me.

Out of curiosity, how do we handle the inline vs. linetable debuginfo issue for the conversion from IRCode to CodeInfo right now?

[serenity4]

I'm not sure I see what you mean? AFAIK both IRCode and CodeInfo have the same DebugInfo representation, except that IRCode holds it uncompressed. And here in the display, it's just a matter of printing.

[topolarity]

AFAIK both IRCode and CodeInfo have the same DebugInfo representation

Ah, you're right. I forgot about that. I was thinking about how inference fills this in at the end: https://github.com/JuliaLang/julia/blob/a4ab11016c0d19cd56b1662afae906afaf8f7a3d/Compiler/src/typeinfer.jl#L130-L138 but it does that regardless of whether we optimize so it's always there when we emit the final CodeInfo.

[serenity4]

That's correct. Seeing the line get_debuginfo(ir_to_codeinf!(result.src)) , I'm thinking we don't even need to turn IRCode into CodeInfo to get its debuginfo (we just need to compress it), but for NativeInterpreter it's still best to use ir_to_codeinf! performance-wise as it is cached and we'll be also calling that ~40 lines of code after.

For verbose_linetable, as it's not documented and fairly internal I guess we can break it and replace it with debuginfo = [:none|:source_inline|:source]? Then I think we can add :source_inline printing to CodeInfo as well and support that in @code_typed etc.

[serenity4]

Then I think we can add :source_inline printing to CodeInfo as well and support that in @code_typed etc.

It's a bit more complicated actually, because we don't have control over the IOContext in which the results are shown, meaning we must actually delete debuginfo (for :none) or leave it as is (for :source). We can't specify how it must print later on.

[serenity4]

It appears we have two different semantics for a debuginfo parameter:

• Preserve/discard debuginfo information (current behavior of @code_typed)
• Control what to print (actually the semantic people expect for @code_typed)

The mismatch between the two expectations in the current state means that we must always show CodeInfo with debuginfo=:source by default (so when printing, if debuginfo information was discarded, it will correctly display none). It's not great but I don't think we can do anything reasonable to improve the status quo.

Therefore I'll go with only supporting a debuginfo context for IRCode/IncrementalCompact (and to some extent CodeInfo but only via show_ir).

[serenity4]

@topolarity shall we merge this?

[topolarity]

we must always show CodeInfo with debuginfo=:source by default (so when printing, if debuginfo information was discarded, it will correctly display none)

This seems strange to me - is it really not possible to mark the debuginfo as discarded and display it "correctly"?

It does make sense that dropping debuginfo in the presentation layer vs. the CodeInfo / IRCode generation would be different things, but I'm not sure I understand why CodeInfo is different than IRCode / IncrementalCompact in that respect

[serenity4]

This is specifically relevant to @code_typed/code_typed, because the reflection function has no control over the user's display (IO context), yet the debuginfo parameter set expectations on what is printed.

Essentially, if we don't special-case CodeInfo, this means that src = @code_typed debuginfo=:source f() may return a src that doesn't print with debuginfo = :source, if the user set a context of :debuginfo => :inline_source or :debuginfo => :none.

I don't think we should make CodeInfo specify in its fields how to be printed. In my opinion the one at fault is @code_typed which sets a printing expectation without actually having control over printing.

[serenity4]

IRCode / IncrementalCompact are not affected because there is no reflection function that sets this expectation (code_ircode does not support debuginfo as a parameter).