Patrick R. Michaud wrote:
Either way works for me -- PCT can generate either without much
difficulty. It probably makes more sense to have separate .file
and .line directives. In particular, I wouldn't want to be
repeating the .file annotation information throughout the bytecode! :-)
Just a reminder that the central issue for PCT and other HLL's
is that the current #line, setline, setfile, etc. instructions
are currently intimately tied to lines of PIR source (RT #43269),
and they probably shouldn't be.
I agree that I don't see a strong need for setting file and
line number dynamically -- at least not at this stage.
Let me clarify a little. The current ".file" and ".line" directives are
tied to PIR lines. That's fine, and I'm planning we can keep things that
way. We could use such a feature now, e.g. in gen_builtins.pir, for
example. It's useful when you're building PIR from other bits of PIR.
But I don't expect PCT will be emitting these two directives.
Instead, I expect PCT will emit .annotate. This allows you to emit
whatever annotations you wish. So you can do file and line annotations,
but you can also choose to do column too if needed. We can use it to
stash away the source code for a sub so we can do .perl for subs, or for
stashing away the compiler version or OS we compiled under for the
various $?FOO variables. When an exception is thrown, we already capture
the location it was thrown from, and thus there will be a way to get
which of these settings were in effect at the point that the exception
was thrown. As an upshot of this, .annotate is not at all tied to PIR
lines - the latest annotation under a given key takes precedence. So you
can emit at the start maybe:
.annotate "file" "foo.pl"
.annotate "compiler" "rakudo-0.1"
And then per line:
.annotate "line" 42
When a new source code line starts.
And yes, I need to get this all into the PIR docs, though the storage
scheme for all of this is in the bytecode PDD already. But it should
give us plenty of flexibility.
Sound good?
Thanks,
Jonathan
