Closed Bug 5872 Opened 26 years ago Closed 26 years ago

xpidl can't keep track of line numbers

Categories

(Core :: XPCOM, defect, P3)

x86
Windows NT
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: waterson, Assigned: mang)

Details

Try inserting some errors into mozilla/rdf/base/idl/nsRDFInterfaces.idl. Maybe the comments screw it up or something.
Status: NEW → ASSIGNED
Marking these as ASSIGNED. Pesky bugzilla-daemon.
Target Milestone: M7
Setting target milestone and adding shaver@netscape.com.
Apparently header and typelib compilation suffer from this problem. I'm experiencing in in header compilation.
scratch that last posting. it is pertinent to forward delcarations, not line numbers.
Assignee: mccabe → mang
Status: ASSIGNED → NEW
Reassigning to mang@subcarrier.org
Status: NEW → ASSIGNED
Target Milestone: M7 → M8
moving this off to m8. tell me if thats not the right thing to do.
I fixed the problem with line numbering not being updated in comments. I'm working on fixing the problem where an error on the first line gets reported as being on line 0.
Things to note: ----------------- iface foo { }; ----------------- produces: foo.idl:0: `iface' undeclared identifier but ---------- #include "foo ---------- produces: didn't find end of quoted include name "foo at foo.idl:1 So you don't want to use increment by one everywhere. It's possible that libIDL's stuff is zero based when it's stuck in IDL_trees.
Running that code through tstidl produces: foo.idl:1: Error: `iface' undeclared identifier And == #include "foo == Produces: inc.idl:2: Error: Empty file I've been trying to figure out what's different.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
libIDL expects the line number to be that of the next line to be processed, so I now initialize the line number to 2 instead of 1.
Component: xpidl → XPCOM
QA Contact: mike+mozilla → xpcom
You need to log in before you can comment on or make changes to this bug.