On Sun, Nov 23, 2008 at 10:08 PM, Jonathan Worthington <[EMAIL PROTECTED]>wrote:
> Klaas-Jan Stol via RT wrote: > >> On Thu Dec 13 04:35:13 2007, pmichaud wrote: >> >> >>> On Sat Sep 29 08:57:28 2007, kjs wrote: >>> >>> >>>> A few months ago, the "#line" directive was implemented. >>>> >>>> I'm wondering what the reason was why it looks like a comment (as # >>>> >>>> >>> will >> >> >>> start a comment). >>>> Is there any reason to not replace this by ".line"? A directive >>>> >>> typically >> >> >>> tells the assembler/compiler something, and in this case it updates >>>> >>>> >>> the line >>> >>> >>>> number. >>>> >>>> >>> As this gets addressed we should also address the handling of the >>> 'setline' opcode (RT #43269). >>> >>> Pm >>> >>> >> >> >> .line directive is implemented per r33084. #line still works. >> >> I'm not sure what Pm meant by addressing the handling of 'setline' opcode, >> so leaving this ticket open. >> >> >> > I'm planning to work on bytecode annotations Real Soon Now...my thoughts on > these issues are: > > * I think .line and .file will remain for setting the PIR-level line and > file (#line and #file maybe too, or we could deprecate those) > Minor detail: .file does not actually exist, except in PIRC. I do not have a strong preference for adding it. Pro: it's a bit clearer than .line, as .line indicates, ehm, the "line" :-) Specifying a filename by .line is a bit weird. Con: generating 2 directives instead of 1 each time you want to update the location makes the generated code string a bit longer/more verbose, which might not be desirable. Anyway, I'm open to anything :-) (possibly renaming even to .location (or .loc, but that's another well-known abbreviation) > > * .annotate "key" value / .annotate "key" "value" will be added for setting > annotations, which will form high level language debug info (.line and .file > may be converted to also store data using the new annotations segment rather > than keeping a separate PIR debug segment in the future; not sure how soon > that will happen, will leave the current debug seg intact for now though) > > * setline and setfile opcodes can probably go away; I can't think of a use > case where we'd want to set these dynamically, since we know the line > number/file number/column/whatever else we wish to store at compile time. > Doing an op dispatch rather than making an annotation we can look up only > when we need it seems odd to me. > I agree. > > Thoughts? > > Jonathan >
