For the same reason as previous commit, the code clang generates for
~AutoOutputRegister when inlined in CacheIRCompiler::emitArrayJoinResult
makes valgrind unhappy. The reason is that TypedOrValueRegister contains
a union with two types of different sizes, where clang makes the code do
a check against the larger variant before validating the union tag says
that's the type in use, and that doesn't go well under valgrind when the
union value was set for the smaller variant.
One way to fix this is to make the TypedOrValueRegister constructor fill
the uninitialized bytes of the union, but it also appears that the types
used in the union, as well as the union tag itself, are larger than they
actually need to be:
- AnyRegister::Code is a 32-bits integer representing a register number,
when no supported platform has more than 254 registers (accounting for
AnyRegister::Invalid),
- MIRType is a 32-bits integer (enum, actually) representing values that
are all below 256.
Changing only the former would make valgrind happy, avoiding the
uninitialized bytes being tested against in ~AutoOutputRegister, but it
was too tempting to do MIRType as well.
clang likes to transform conditions like:
if (A && B)
into
if (B && A)
where B might be undefined when A is true (or variants of the above with
! and ||, or split between multiple ifs). This doesn't go well with
valgrind, although it's valid (albeit seemingly convoluted).
In both cases fixed here, the condition A involves calling a function
with a pointer to a variable on the stack that may or may not be filled
by the function call, and the condition B checking the value of said
variable.
This allows JS callers to automatically get the correct types during
interation, without having to explicitly specify them.
Differential Revision: https://phabricator.services.mozilla.com/D3728
--HG--
extra : rebase_source : b708f382d8ea571d199c669bfed5b5a7ca9ffac4
extra : histedit_source : 7df6feb82088c8a5ca45dc28fe4d2b852c177fee
This patch allows us to define methods or getters/setters for any of the
current set of well-known symbols. Those are defined by adding the [symbol]
attribute to a method:
[symbol]
Iterator iterator();
which causes the method to define a property with the well-known symbol which
matches its method name (Symbol.iterator, in this case).
Due to the implementation details of the XPIDL parser, this currently does not
support defining a non-symbol function with the same name as a symbol
function:
[symbol]
Iterator iterator();
[binaryname(OtherIterator)]
Thing iterator(in nsIDRef aIID);
throws for a duplicate method name, even though there is no actual conflict.
Differential Revision: https://phabricator.services.mozilla.com/D3724
--HG--
extra : rebase_source : 1385e2da93113306730f7c087fe7385dbe668e91
extra : histedit_source : 3afd9fe38e7cbddc5576c2bd1673496dd623e489
- Move SimpleTypeDescrKey functions into CacheIR.h. This matches the set of callers
- Move LoadTypedThingData into CacheIRCompiler, matching usage
- Push definition of StripPreliminaryObjectStubs up in file, and remove header declaration
- Consolidate LoadTypedThingLength into CacheIR files
- Remove now dead ICMultiStubCompiler
- Remove BinarySharedStub classes. Can do this now that Compare and BinaryArith ICs have been converted to CacheIR
- Rename comapreSharedStub, and use correct flag to disable it.
- Remove SharedStubInfo
- Collapse SharedICList.h back into SharedIC.h
- Remove unimplemented declaration
--HG--
extra : rebase_source : 8ac2b2644d970e0828903f91035c1b692874b203
Fixes a hazard introduced by allowing the analysis to correctly see through more of the callgraph.
--HG--
extra : topic : hazard
extra : rebase_source : a2b20f3a4c5127c502c1402ca9abbd1e2ad0d382
Benjamin Bouvier
Mike Hommey
Tooru Fujisawa
Kris Maglione
Sean Stangl
Luke Wagner
Matthew Gaudet
Jon Coppeard
Steve Fink
Nicolas B. Pierron
Gurzau Raul
Csoregi Natalia
Lars T Hansen
Jan de Mooij