Closed Bug 6523 Opened 25 years ago Closed 13 years ago

xpidl should use #line, #file directives for %{ blocks

Categories

(Core :: XPCOM, enhancement, P3)

enhancement

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: mike+mozilla, Unassigned)

Details

Attachments

(1 file)

Thanks to waterson for this suggestion - xpidl should use #line, #file directives for %{ blocks. Maybe not for generated .h proper, as xpidl will munge the original .idl arbitrarily in creating the generated .h. But %{ blocks come directly from the .idl file, so we might as well point compilers and debuggers to the correct place.
What's the format for these under our various compilers? GCC expects: #line <linenum> "/path/to/file.idl"
Status: NEW → ASSIGNED
Changing status to assigned, and cc'ed Mike Ang. Pesky bugzilla daemon.
I've mostly got this working - diff attached. One open question: I currently just put a filename in the #line directive without any path information. What path information is correct? Is it needed for debuggers to be happy? Can it be made to work with our build system, copying headers on win32, etc?
[SPAM] Marking milestone 'future' as part of nsbeta3 triage.
Target Milestone: --- → Future
Mass-reassigning mccabe's non-JS, non-Rhino bugs to jband (34 total). Would like to cc mccabe; but the mass-reassign page does not allow this. I'll leave it up to mccabe to decide if he wants to be cc'ed on these -
Assignee: mike+mozilla → jband
Status: ASSIGNED → NEW
mass reassign of xpidl bugs to dbradley@netscape.com
Assignee: jband → dbradley
Status: NEW → ASSIGNED
Assignee: dbradley → nobody
Status: ASSIGNED → NEW
QA Contact: mike+mozilla → xpidl
Component: xpidl → XPCOM
QA Contact: xpidl → xpcom
I'm not interested in taking a patch for this, especially since it's most useful for %{C++ blocks which are uncommon.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: