Removes the XPCOM interface for nsIDOMHTMLMenuItemElement, replacing it
with binding class usage.
MozReview-Commit-ID: 9HtCmwKyV1W
--HG--
extra : rebase_source : d56ee91a46d48c9d8698765b520a585361813a26
This change requires introducing nsID::Clone(). Because it's infallible, the
patch also removes some redundant failure-handling code. (nsMemory::Clone() is
also infallible, so this code was redundant even before this change.)
--HG--
extra : rebase_source : ef22757d3fa814320490bf7e19e822b8f0c4bdc3
They are equivalent -- both infallible, both requiring measuring the length of
the string -- but moz_xstrdup is much more readable. (One place deals with
16-bit strings and so uses NS_strdup instead, which is also infallible.)
The patch also removes some failure-path code that will never execute due to
the infallibility.
--HG--
extra : rebase_source : 115574cf55db90b60e6bee59e5dc6ee409374159
This Makefile.in contains a bunch of cruft for Tier-3 platforms. If
someone is still supporting any of them they can make the necessary
fixes to moz.build files themselves.
MozReview-Commit-ID: HxbbCv395Y5
--HG--
extra : rebase_source : 94f04128d2b3dd1285dfeafbfeb320b2f0d0bb19
extra : histedit_source : 2353127161ae58e54b6296e98b6b4b972ae439fe
Removes the XPCOM interface for nsIDOMHTMLCanvasElement, replacing it
with binding class usage.
MozReview-Commit-ID: DQJhqGlY8U6
--HG--
extra : rebase_source : a33146a22ee356a0840bb9fef82d51b2b315f6d7
Removes the XPCOM interface for nsIDOMHTMLAreaElement, replacing it
with binding class usage.
MozReview-Commit-ID: IaX4JFTPZn6
--HG--
extra : rebase_source : 79f9200c6ff9e081a5d9bc21eaa605f88caa99e9
Removes the nsIDOMHTMLObjectElement XPCOM interface, replacing it with
HTMLObjectElement and FromContent conversion usage.
MozReview-Commit-ID: dmsjSO97uh
--HG--
extra : rebase_source : 9b2c25b8681f754bc34233afccdb6fc5d38f0804
XPConnect wrapper overhead for this interface has been showing up heavily in a
lot of my profiles, in some places accounting for 50ms of the 80ms we spend
getting getting <browser> messageManagers. This improves the situation
considerably.
MozReview-Commit-ID: 9d1hCORxsYG
--HG--
rename : dom/base/nsIFrameLoader.idl => dom/webidl/FrameLoader.webidl
extra : rebase_source : d8a1fc1a19632ba36a9fc6f63873f7534671a13b
This is straightforward, with only two notable things.
- `#include "nsXPIDLString.h" is replaced with `#include "nsString.h"`
throughout, because all nsXPIDLString.h did was include nsString.h. The
exception is for files which already include nsString.h, in which case the
patch just removes the nsXPIDLString.h inclusion.
- The patch removes the |xpidl_string| gtest, but improves the |voided| test to
cover some of its ground, e.g. testing Adopt(nullptr).
--HG--
extra : rebase_source : 452cc4a08046a1adb1a8099a7e85a1917de5add8
Removes nsIDOMHTMLEmbedElement and all references. HTML elements are
now handled by WebIDL. With the deprecation of extensions, XPCOM
interfaces to HTML elements are no longer needed.
MozReview-Commit-ID: DI4XVvdgPDI
--HG--
extra : rebase_source : 74bd92619e3d1db04c3dd40ec3022474fe1d647c
Removes applet tag interfaces, and changes HTML5 parser to output
HTMLUnknownElement when tag is found. Removes tag process from various
places in the browser.
MozReview-Commit-ID: 2zHhK2U2esX
--HG--
extra : rebase_source : d06ecaffd1cb656301e29b900bafde4c68a4606e
Add breakpoint support for AArch64, and fix a scanf format specifier
warning. Also fix an #if line in xptcinvoke_arm.cpp to work as intended.
MozReview-Commit-ID: BSjYVD8Zq0t
Other browsers do not support any of these (IIRC), telemetry reports
essentially zero usage, and supporting them is contrary to the DOM spec.
Notes on specific events:
CommandEvent and SimpleGestureEvent: These are not supposed to be
web-exposed APIs, so I hid the interfaces from web content too
(necessary to avoid test_all_synthetic_events.html failures).
DataContainerEvent: This was a non-standard substitute for CustomEvent
that seemed to have only one user, so I removed it entirely and switched
the user (MozillaFileLogger.js) to CustomEvent.
ScrollAreaEvent: This is entirely non-standard, but we apparently expose
it deliberately to web content, so I didn't see any reason to remove it
from createEvent.
SimpleGestureEvent and XULCommandEvent: Can still be created from
createEvent(), but not by content.
TimeEvent: This is still in because it has no constructor, so there's no
other way to create it. Ideally we'd update the SMIL spec to add a
constructor. I did remove TimeEvents.
MozReview-Commit-ID: 7Yi2oCl9SM2
--HG--
extra : rebase_source : 199ab921acfc531b8b85e77f90fcd799b03c887b
In the 32-bit parisc runtime, the first four non floating-point
arguments are passed in registers (%r26, %r25, %r24 and %r23).
The remaining arguments are passed on the stack. There are four
reserved slots on the stack that the callee can use to save the
first four argument registers if the callee desires.
The StubN functions are special in that arguments are not explicitly
declared. %r26 is used for the "self" pointer. The call to SharedStub(n)
loads n into %r26 and clobbers the "self" pointer in %r26. The hppa
SharedStub implementation expects to find the "self" pointer on the
stack in the slot reserved for StubN. However, gcc doesn't copy any
arguments to the stack as no arguments are declared for StubN. Even
if it did, there's no guarantee that we could force gcc to save the
argument on the stack as that's more expensive than copying to a
free register. Thus, we need to copy %r26 to the stack slot manually.
The invoke_copy_to_stack() function passes incorrect "stack_args" and
"end" arguments to the alloc_word() utility function, for parameter types
T_I8..T_I64, T_U8..T_U64, T_BOOL, T_CHAR and T_WCHAR.
Namely, the "end" input parameter of invoke_copy_to_stack(), which is
currently incorrectly passed as "end" to alloc_word(), points to the very
end of the entire exchange area between _NS_InvokeByIndex() and
invoke_copy_to_stack(). However, alloc_word()'s "end" parameter should
point to the end of the "ireg" (integer registers) sub-area of the
exchange area. That is, "ireg_end" should be passed to alloc_word() as
"end".
Because invoke_copy_to_stack()'s "end" input parameter is strictly greater
than "ireg_end", alloc_word() will happily trample over the "freg"
(floating point registers) area, on the above-mentioned type branches,
given a large enough "paramCount".
Similarly, as second argument, "stack_args" should be passed to
alloc_word(), pointing to the next available stack slot, for spilled-over
arguments. Passing "stk", which initially points to the base of the entire
exchange area (and hence the base of the "ireg" area) makes no sense.
The two other alloc_word() calls in the function are correct. So
centralize all calls to alloc_word() to a single location -- thereby
ending up with a sole call site per alloc_XXX() function --, and compute
only the last argument, "word", conditionally.
This fixes an obscure SIGSEGV in AARCH64 Firefox. Triggering the bug
requires a target function with seven integer-like parameters (not
counting the implicit "this" -- aka "that" -- parameter), followed by at
least one parameter of the above buggy types. nsIOService::NewChannel2()
is such a target function, for example.
DONTBUILD because NPTOB
This patch removes checking of all the callback calls in memory reporter
CollectReport() functions, because it's not useful.
The patch also does some associated clean-up.
- Replaces some uses of nsIMemoryReporterCallback with the preferred
nsIHandleReportCallback typedef.
- Replaces aCallback/aCb/aClosure with aHandleRepor/aData for CollectReports()
parameter names, for consistency.
- Adds MOZ_MUST_USE/[must_use] in a few places in nsIMemoryReporter.idl.
- Uses the MOZ_COLLECT_REPORT macro in all suitable places.
Overall the patch reduces code size by ~300 lines and reduces the size of
libxul by about 37 KiB on my Linux64 builds.
--HG--
extra : rebase_source : e94323614bd10463a0c5134a7276238a7ca1cf23
I think technically you could implement one of these in JS now, which
might prevent me from reasonably asserting that these can never GC. I
doubt anybody would ever do that, so it should be okay. There are zero
references to these two interfaces in all of addon DXR, and none in
Firefox JS.
MozReview-Commit-ID: 3AkW0AkqmNx
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
When using GetIIDForParamNoAlloc to get return paramter type, if param is nsIDOM*, it should get it by GetShimForParam.
When this situation, GetEntryFor Param tries to get nsIDOMDocument, so GetEntryForParam doesn't get entry. Then, GetShimForParam tries to get entry. But since it doesn't traverse parent objects, it will try to get nsIDocShell instead.
So it might not get correct entry.
MozReview-Commit-ID: LaOVymgFMgi
--HG--
extra : rebase_source : 9ce3b38872dd6bcabd473296cc5bda25c7d5ceab
extra : histedit_source : 385797913a2d76e2981b4106d572edd784145126
A few callers of NS_NewISupportsArray() didn't use the return value to detect
failure, but instead checked if the |array| argument was null after the call.
This is inconsistent with the majority of the calls to NS_NewISupportsArray().
This patch changes them to be checked in the normal way.
--HG--
extra : rebase_source : bf91836d7c3b159833c303a3716f4d9366f8b76a
This patch makes NativeProperties variable-length and reduces static data by
110,336 bytes on 64-bit, and half that on 32-bit.
MozReview-Commit-ID: 2etZ5AnEhgO
--HG--
extra : rebase_source : 6a167b64df7da3c6940114782fe08337f04a694d
This patch:
- Removes XPTArena's ability to support arbitrary alignments.
- Hardwires two sub-arenas into XPTArena, one with alignment of 8 and one with
alignment of 1.
- Uses the first sub-arena for most allocations and the second sub-arena for C
string allocations.
These changes reduce "xpti-working-set" by 56 KiB.
The patch also renames all the used of "malloc" in XPT identifiers with
"calloc", to make clearer that the result is always zeroed.
--HG--
extra : rebase_source : 8e6cc42644621a7f3c80593006734e25420c7229
With careful layout we can reduce sizeof(XPTTypeDescriptor) from 4 to 3, which
also reduces sizeof(XPTParamDescriptor) from 6 to 4. This reduces
"xpti-working-set" by 16 KiB.
The union-of-structs also improves readability by making it clearer exactly
which fields are used for which types.
--HG--
extra : rebase_source : 08060096f93c756fda847b90b45df1b1b207e2b5
RegisterBuffer() is the only place that creates an XPTState, and it also
destroys it. So the XPTState can be allocated on the stack, which voids the
need for the creation of an XPTArena.
--HG--
extra : rebase_source : b25f0e798d72b8742efc96793a927f8a060101cf
Currently XPT can both encode and decode, but encoding has been handled by
Python code since bug 643817, so the encoding support can be removed. This
results in many simplifications. Some notable changes:
- All the XPTHashTable code (including XPTDatapool::offset_map) is no longer
necessary.
- PrimitiveTest.cpp and SimpleTypeLib.cpp both don't make much sense without
encoding support, so I removed them.
- A lot of the version code was already unused, e.g. XPT_VERSION_*,
XPT_TYPELIB_VERSIONS_STRUCT, XPT_TYPELIB_VERSIONS.
XPT_MAJOR_INCOMPATIBLE_VERSION is the only thing actually used in version
checks.
- The patch also removes some code that was dead even before encoding removal,
such as XPT_ParseVersionString().
--HG--
extra : rebase_source : 11cfe0b01efde4e2ff0c74b02b408baebedd3dd8
On win32, NS_InvokeByIndex is implemented with inline assembly. This
inline assembly assumes that it is wrapped by the compiler with the
standard x86 prologue and epilogue:
push ebp
mov ebp, esp
[inline assembly that manipulates the stack pointer]
pop ebp
ret
In particular, the last instruction of the inline assembly is:
mov esp, ebp
which cancels out the effects of the stack manipulation performed by all
the inline assembly that proceeds the instruction.
When compiling with clang-cl, however, the above assumption does not
hold, as clang-cl inserts a more complex prologue and epilogue,
something like:
push ebp
mov ebp, esp
sub esp, frame_size
[save registers into stack frame]
[inline assembly that manipulates the stack pointer]
[restore registers from stack frame]
add esp, frame_size
mov esp, ebp
pop ebp
ret
Combining this more extensive prologue and epilogue with the assumptions
of the inline assembly leads to interesting crashes when
NS_InvokeByIndex is called: the inline assembly effectively deallocates
the stack allocated by the inline assembly *and* the stack frame
allocated by the compiler itself. The compiler-generated code then
attemptes to deallocate the stack frame, leading to the crash, as the
code now returns to an unspecified address.
To avoid these sorts of problems in clang-cl and make the code more
robust generally, let's move the NS_InvokeByIndex implementation to a
separate assembly file. We can then write exactly what we need to have
happen, safe from any manipulations of the compiler.
Since we don't compile much (any?) code in Gecko with MASM, we need to
add the /SAFESEH flag to the assembler invocation so that the object
file with be appropriately marked as not containing exception handlers;
the linker (which is invoked with the /SAFESEH flag itself) will then
consent to link it into libxul.
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
xptcstubs_arm mostly works on iOS but Apple's assembler is ridiculous so
the inline assembly for the SharedStub and the stub methods needs judicious
preprocessor use.
--HG--
extra : commitid : ChAcktTzVX0
extra : rebase_source : 11fbaa4940fd9aaeba51e2477d4c8b1a7851791e
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
After this change, we have ShallowSizeOf{In,Ex}cludingThis(), which don't do
anything to measure children. (They can be combined with iteration to measure
children.)
--HG--
extra : rebase_source : f98420176f50990bbc5a25e35788328154cfeb00
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
Adding isMainProcessScriptable() into the middle of nsIInterfaceInfo
caused problems with some binary addons that relied on the ordering of
the methods in nsIInterfaceInfo. In an attempt to placate those addons,
move isMainProcessScriptable() to the end of the vtable. This change is
a no-op for normal libxul usage.
Constructing kComponentsInterfaceShimMap required a static constructor
on some compilers, due to a non-constexpr constructor and the necessity
of copying non-constexpr things like nsIID. This static constructor is
large (several kilobytes of object code on x86-64) and completely
unnecessary.
To fix this, let's add a constexpr (well, MOZ_CONSTEXPR) constructor to
ComponentsInterfaceShimEntry. This change alone doesn't completely
solve our problem, because the nsIID member still needs to be copied.
But doing that copying is silly: we only use the IID for constructing a
ShimInterfaceInfo in ShimInterfaceInfo::MaybeConstruct, and the
ShimInterfaceInfo constructor takes a const reference. So let's store a
const reference in ComponentsInterfaceShimEntry, too, and make that
structure significantly smaller in the process.
As explained in bug 1111355, having avx enabled appears to change the
alignment behavior of alloca (apparently adding an extra 16 bytes) of
padding/alignment (and using 32-byte alignment instead of 16-byte). The
suggestion of using __bultin_alloca_with_align in bug 1111355 didn't fix
the problem, so this seems to be the best available workaround, given
that this code, which should perhaps better be written in assembly, is
written in C++.
Interestingly, this is NOT fixed by #pragma GCC target ("arch=x86-64").
(I determined the (undocumented) name for the default -march value on
x86_64 from the gcc source code (gcc/config/i386/i386.c, function
ix86_option_override_internal, code that sets opts->x_ix86_arch_string .)
I confirmed that this sets the same macros based on the empty diff
between the output of 'gcc -E -dM -x c++ /dev/null' and 'gcc -E -dM -x
c++ -march=x86-64 /dev/null', which was not an empty diff for other
-march values (e.g., k8).)
I confirmed that the push_options and pop_options actually work by
putting the push/pop pair around a different (earlier) function, and
testing that this did not fix the bug (with the pop_options before
NS_InvokeByIndex).
See the gcc documentation at:
https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Function-Specific-Option-Pragmas.htmlhttps://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Function-Attributes.htmlhttps://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/i386-and-x86-64-Options.html
--HG--
extra : transplant_source : %DA%7CJ4H%DE%80%15%84%0D%116%85Q%9A%F9%2C%D1v%16
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
This fixes the download panel issue, and brings us revs 727721e5d8ac,
844b142d8111 and 236989b3a807 as a bonus. Remove the unmaintained
OpenBSD/amd64 specific versions.
OS_LIBS for libraries that are not part of the gecko tree, EXTRA_LIBS for
libraries, such as NSPR, that are in the tree, but are not handled by
moz.build just yet. Those EXTRA_LIBS may also come from a system library.
However, in cases where the expanded variables are always empty for the
in-tree case, OS_LIBS is used (as for, e.g. MOZ_ZLIB_LIBS). OS_LDFLAGS is
used exclusively for non-library linker flags.
Always pass EXTRA_LIBS before OS_LIBS on linker command lines.
Forbid EXTRA_DSO_LDOPTS, SHARED_LIBRARY_LIBS and LIBS in Makefiles.
This warning isn't that helpful anymore, because it means that we don't
have interface info from an .xpt. For DOM interfaces, that's OK,
because we'll have shimmed interface info instead. So just remove the
warnings.
This patch does all the interesting work: we check for shims whenever we get
asked about parameter information for methods. If there's a shim for what we
want, we ask the shim to provide the information. If not, we fail as usual.
The code that looks up |xptiInterfaceEntry|s starts by figuring out where in
the typelib the desired entry lives. We want to do the same thing for the
purpose of getting shims, so we can ask the typelib for the name of the thing
at that index. Split out a method to do this for us.
xpt linking works with two different currencies: UUIDs of interfaces, and names
of interfaces. Names are how we support linking in unknown-at-compile-time
interfaces at runtime. Since we need to know names to decide whether we have
shims for interfaces or not, we need a method for exposing the names.
It's just as easy to directly set the preprocessor macro in the moz.build
files. Using this variable doesn't really buy us anything.
This patch also removes unused code from rdf/tests/dsds.
