xpidl fails on .idl than contains only #includes

RESOLVED FIXED in Future

Status

()

Core
XPCOM
P3
normal
RESOLVED FIXED
18 years ago
10 years ago

People

(Reporter: Mike McCabe, Assigned: Mike McCabe)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

18 years ago
Message from Warren -


Mike, 

I wanted to include a bunch of idl files in another for convenience to the user,
but hit this compiler warning: 
  

** WARNING **: Parse of nsplugin.idl failed

<unknown file>:-1: File empty after optimization

NMAKE : fatal error U1077: '..\..\..\dist\WIN32_D.OBJ\bin\xpidl.exe' : return
code '0x1'

Stop.

NMAKE : fatal error U1077: 'C:\msdev\VC98\bin\nmake.EXE' : return code '0x2'

Stop.


Compilation exited abnormally with code 2 at Fri May 19 20:49:18

This caused me to have to throw a dummy interface definition (nsIDummy -- I
couldn't name it _dummy!) in the file. Can you remove this restriction? 

Warren
(Assignee)

Comment 1

18 years ago
Fix in hand, attaching.

Warren, could you review?  It's something of a hack, as libIDL lacks the API
needed to detect just why it failed on parse.
(Assignee)

Comment 2

18 years ago
Created attachment 8924 [details] [diff] [review]
Detect parse failure because of empty IDL and emit prolog and epilog anyway

Comment 3

18 years ago
I suppose that patch looks alright, although I haven't tried it. 

But rather than saying an empty file is ok, why not just make it so that when 
foo.idl includes bar.idl, and the generated foo.h includes bar.h, then this case 
isn't considered empty (i.e. including something is just as valid as defining 
something). Same goes for other top-level statements, e.g. %{C++ ... %}, etc.
(Assignee)

Comment 4

18 years ago
This is a reasonable request, but it's architecturally tricky.  It happens that
IDL is handled by the libIDL parser we get from GNOME... and #include statements
are handled by the xpidl frontend (the input callback, actually).  Rather than
introduce more "OK if it's this but not if it's this" logic, I'd prefer to do
the simple thing and just accept empty input.

Our hands are somewhat tied by using libIDL as our parser, as we cannot easily
change it.  I'm considering brining it into our tree for other reasons, but we
shouldn't gate this on that.  (And I think allowing empty files is a more
rational behavior...)
(Assignee)

Comment 5

18 years ago
[SPAM] Marking milestone 'future' as part of nsbeta3 triage.
Status: NEW → ASSIGNED
Target Milestone: --- → Future

Comment 6

18 years ago
Doing a string comparison of the error message seems rather fragile.  That said,
I'm not sure how else we can do this given the current API.

The patch looks correct and works for me, though I wish there were a better way
to do it without changing libIDL.
r=mang (peer)

Comment 7

18 years ago
cc'ing Andrew Veliath (hope andrewtv@usa.net is still the right address)

Andrew, is there a better way to detect the case of an empty input file?

Comment 8

18 years ago
sr=jband
(Assignee)

Comment 9

18 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Updated

10 years ago
Component: xpidl → XPCOM
QA Contact: mike+mozilla → xpcom
You need to log in before you can comment on or make changes to this bug.