11199 - xpidl should remove output file on failure

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P3)

Description

[Mike McCabe]

Currently, some kinds of compilation failure have xpidl returning false, but
leaving a half-constructed output file.  This could be confusing.

Comment 1

[Mike McCabe]

Marking as assigned.

Comment 2

[Mike McCabe]

This is a problem because if there's an .idl file for which xpidl fails for some
late-detected error, a truncated .h file still gets generated... and a
subsequent make in the same directory will succeed.  A pain when developing.

Fix in hand for unix and (I believe) win32.  I found NSPR code in
macio.c:_MD_Delete to delete a file, but it's scary.  Patrick, any suggestions?
Is this even a problem on the mac?

Comment 3

[chris hofmann]

lets get this done in m13

Comment 4

[Patrick C. Beard]

If you do remove objects on the Mac, the IDE goes ahead and deletes the output
files. I can add code to the drop-in compiler to delete as well, since I know
which file is the output file.

Comment 5

[Mike McCabe]

Fix checked in for Unix and Windows; punted on the Mac.

Patrick, can you take this?  Closing it and also punting is also an option.

Comment 6

[Patrick C. Beard]

Checked in a fix for this. Let me know if it works. I need some kind of file
with an error in it that demonstrates the bug.

Comment 7

[Mike McCabe]

Removing the output file when xpidl returns an error should do the trick.
Thanks for fixing this!

This problem cropped up when error s were detected at output-generation time
(after parsing.)  An example problem is marking an interface as scriptable when
it contains non-scriptable methods, such as methods with native return types.
Previous to this fix, if you compiled such a file with the make system, you'd
get an error (and an aborted make) the first time you compiled the file, but on
the second time, the make system would detect a partial file with a correct
timestamp, and wouldn't try to recompile the file.