The other fields, spec, array, and nullable, are set in some places.
Also remove a dead chunk of code with a FIXME that refers to a bug
that was WONTFIXed in 2010.
--HG--
extra : rebase_source : 184d001a1233e9c035af070bc920c8cbeabc27cc
MessageId has the production "'~' ID", but if you use it, it produces
an error. This error was added in 2009, in bug 525342. I doubt anybody
expects it to work any more, so it should just be a regular parse
error. This is the only usage of the literal ~ so it can now be
removed from there.
MozReview-Commit-ID: AivlLE8Nubv
--HG--
extra : rebase_source : 66f76d1528f0bcf624af97b9437834874e537eb8
We will use the new type for the generated IPDL message handler
prototype to make sure correct error handling method is called.
MozReview-Commit-ID: AzVbApxFGZ0
The IPDL parser handles include statements by using a stack of
parsers. If an inner parser encounters a parsing error, it will print
out an error message, which is maybe okay, but then it makes two
mistakes:
1. It does not pop the current parser off of the parser stack. This
means that the file that included the syntactically invalid file will
be parsed as though it were the invalid file. In bkelly's case, an
.ipdl file included an invalid .ipdlh file, so he got a bizarre error
message about how you can't define a protocol in a header, because the
parser was treating the protocol in the .ipdl file as though it were
in the .ipdlh file. I fixed this by using a "finally" clause to pop
the parser stack, ensuring that it is correct even in case of error.
2. A parse error in the include should cause the entire parse to fail,
but instead it will keep going. inc.tu will get set to None, which
eventually causes an error later in type checking, when it attempts to
examine inc.tu. I fixed this by only catching the parse error where we
invoke the outermost parser. This has the drawback that later errors
in other files will not be reported. An alternate fix would set a
global flag to indicate that a parse error had occured, and somehow
report that to the caller.
I think this bug was introduced in 2009 by commit
cb8189926a69872c73508fba50830f0d07af341f.
MozReview-Commit-ID: DhbDUO7MXGB
--HG--
extra : rebase_source : cee371cd54ebf575f78aa8b2441afbde8b3c2b8f
Giving '0' (literal zero) to RefPtr is now ambiguous, as both
RefPtr(decltype(nullptr)) and RefPtr(T*) could be used.
In any case, our coding standards mandate the use of 'nullptr' for pointers.
So I'm changing all zeroes into nullptr's where necessary.
MozReview-Commit-ID: A458A4e9for
--HG--
extra : rebase_source : bc4107ce1767329e3dddfe34c55ba79202192e06
Preloading libmozsandbox allows the symbol interpositions used by
sandboxing to be defined there instead of statically linked into the
executable; this patch also does that.
MozReview-Commit-ID: FL1QWLSKA0S
--HG--
rename : security/sandbox/linux/interpose/SandboxHooks.cpp => security/sandbox/linux/SandboxHooks.cpp
Phil Ringnalda
Ehsan Akhgari
Wes Kocher
Aaron Klotz
Carsten "Tomcat" Book
Andrew McCreight
Kan-Ru Chen
Chris Peterson
Thinker K.F. Li
Randall Barker
David Anderson
Andrea Marchesini
Gerald Squelart
Olli Pettay
Christoph Kerschbaumer
Michelangelo De Simone
Sebastian Hengst
Jed Davis
Jacek Caban
Bill McCloskey