Cédric Belmant

Could this have something to do with [these lines](https://github.com/JuliaCollections/OrderedCollections.jl/blob/master/src/ordered_dict.jl#L432-L435)? Maybe `jl_arrayunset` is called with invalid arguments or something like that. But that's just a guess, I'm not familiar with these...

Apparently an error with out of bounds indexing according to [this comment](https://github.com/JuliaLang/julia/issues/45959#issuecomment-1177886340)

We can discuss that when we actually have things to demo/show off. For now it is perhaps a bit premature. The simplest currently is to stick to tutorials that go...

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...

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...

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...

> 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...

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...

@topolarity shall we merge this?

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,...