Sort out why the _Throw() hack doesn't work on VC10, and find an alternative

RESOLVED FIXED in mozilla1.9.3a5

Status

()

defect
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: cjones, Assigned: cjones)

Tracking

(Depends on 1 bug)

Trunk
mozilla1.9.3a5
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

No description provided.
Version: unspecified → Trunk
VC10 departs from the VC9/8/7 exception-throwing strategy pretty significantly.  There appear to be two ways "exceptions" are "thrown": (i) by a _RAISE() macro that calls _invoke_watson() in _HAS_EXCEPTIONS=0 code; (ii) by _X[exception]() functions exported by the CRT, e.g. _Xout_of_range() (like gcc).  (i) isn't so bad, but (ii) results in C++ exceptions being thrown from the CRT (since it's _HAS_EXCEPTIONS=1), and that's bad.  This patch again grossly interposes our definitions of these, and part of me died as usual.

That said, if we want to switch releasing VC builds, we might want this patch eventually for another reason: whether or not |if _HAS_EXCEPTIONS|, xul.dll will retain a link-time dependency on the _X[exception] functions.  They're not exported by the <=VC9 CRT, which means that eventually the successor of bug 557060 would be filed.  Small benefit, yes, but hopefully it'll wash out some of the mouth-vom.
Assignee: nobody → jones.chris.g
Attachment #440710 - Flags: superreview?(benjamin)
Attachment #440710 - Flags: review?(ehsan)
Comment on attachment 440710 [details] [diff] [review]
Interpose mozilla variants of functions that throw exceptions from the VC10 STL

I'm sad that we have to do this, but I think this is the best we can currently do.  r=me.
Attachment #440710 - Flags: review?(ehsan) → review+
Attachment #440710 - Flags: superreview?(benjamin) → superreview+
http://hg.mozilla.org/mozilla-central/rev/6e7fe366cab7
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
This checkin caused Thunderbird/SeaMonkey breakage, from a fast glance I'd say LDAP needs some change to build with this, but I'm not digging deeper as Standard8 has already been looking into it and says he probably has a fix but still needs to test it.
Depends on: 562655
Target Milestone: --- → mozilla1.9.3a5
Depends on: 609188
You need to log in before you can comment on or make changes to this bug.