Newer versions of clang warn about this construct, as the behavior is
not consistent between compilers. These warnings break
warnings-as-error builds, and seem like reasonable warnings to fix, so
let's do that.
X86_OR_PPC was only used in one place, so inlining it and getting rid of
the definition seemed reasonable.
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 8f5061080a3d56dd484f9be03649fb65f0145f67
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 22ab4f47661ead4995d0c5261104abfb02b82aa2
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 94527a0be3f107991998185903f1c6cf6e190f9f
Detecting AVX2 requires the use of a sub-leaf.
To make things easier we remove our use of the cpuid.h
implementation on GCC and just use our existing inline asm
implementation.
arm.h still have CPU feature detection for Microsoft Compiler that is used by WinCE. Since we don't have the target for WinCE, we should remove it.
Also, even if you need it for Win32/arm that is Windows Mobile and Windows IOT in feature, this is unnecessary. Win32/arm ABI requires thumb2+NEON at least.
MozReview-Commit-ID: 6dYjIRY0Suo
--HG--
extra : rebase_source : 34db8ed7d3d60bafdfc735b036e891554a0e56c5
Without this change, Visual Studio 2015 complains:
mozglue/misc/StackWalk.cpp(261): warning C4477: 'fprintf' : format
string '%s' requires an argument of type 'char *', but variadic argument
2 has type 'LPVOID'
MozReview-Commit-ID: HIAs5L57Nd1
--HG--
extra : rebase_source : 1ac50c03c4d6b14e22f3d55aca026fce15565f5c
There are two instances:
- MappableSeekableZStream::Create uses ScopedDeletePtr, which is
actually a little odd, since MappableSeekableZStream, as a Mappable,
is refcounted, and it's unusual to use two different kinds of smart
pointers for a single class. I think the more natural thing would be
for MappableSeekableZStream::Create to return an already_AddRefed, but
that change spirals out of the realm of "simple refactoring" quickly.
- SzipCompress::run uses ScopedDeletePtr along with some dubious use of
raw pointers. I changed things out for UniquePtr and also tidied the
memory management a bit, which I think makes things a little clearer.
This patch introduces a small utility program to extract a guid from a shared library
or executable on windows to identify the correct symbol file to read in fix_stack_using_bpsyms.py.
In order for this to work correctly on windows, the library name provided by
MozDescribeCodeAddress needs to be a full path, so the LoadedImageName field
from the IMAGEHLP_MODULE64 structure is used here instead of the ModuleName
field.
MozReview-Commit-ID: 8zkfLWjKVs2
This patch introduces a small utility program to extract a guid from a shared library
or executable on windows to identify the correct symbol file to read in fix_stack_using_bpsyms.py.
In order for this to work correctly on windows, the library name provided by
MozDescribeCodeAddress needs to be a full path, so the LoadedImageName field
from the IMAGEHLP_MODULE64 structure is used here instead of the ModuleName
field.
--HG--
extra : commitid : GwkhBdm81g3
This patch turns NativePanZoomController's MotionEvent handler into a
native method, and it adds the WrapForJNI annotations to all native
methods so that bindings will be automatically generated for them.
Also, in the unlikely case none of the supported methods is available, error
out at compile time, because it's not supposed to happen, apart if something
like what bug 989499 did happens again.
In Java we will call this method with byte array buffers we use to read from a stream. Java does not
guarantee to completely fill the buffer (and can't at the end of a stream). Passing the number of bytes
to read from the array to NativeCrypto avoids copying bytes between arrays of various lengths.
--HG--
extra : commitid : 7Vp3hqUE08T
extra : amend_source : 89845bccc20cfe36b421a568e52bdaa1be2f2800
We can do better than use raw new[]/delete[] calls all over this file:
we can factor out the code for APK library loading into a separate
function, and use UniquePtr there. This refactoring will also
centralize the code for determining the path to a library within the
APK.
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
This commit was generated using the following script, executed at the
top level of a typical source code checkout.
# Don't modify select files in mfbt/ because it's not worth trying to
# tease out the dependencies currently.
#
# Don't modify anything in media/gmp-clearkey/0.1/ because those files
# use their own RefPtr, defined in their own RefCounted.h.
find . -name '*.cpp' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
grep -v 'mfbt/RefPtr.h' | \
grep -v 'mfbt/nsRefPtr.h' | \
grep -v 'mfbt/RefCounted.h' | \
grep -v 'media/gmp-clearkey/0.1/' | \
xargs perl -p -i -e '
s/mozilla::RefPtr/nsRefPtr/g; # handle declarations in headers
s/\bRefPtr</nsRefPtr</g; # handle local variables in functions
s#mozilla/RefPtr.h#mozilla/nsRefPtr.h#; # handle #includes
s#mfbt/RefPtr.h#mfbt/nsRefPtr.h#; # handle strange #includes
'
# |using mozilla::RefPtr;| is OK; |using nsRefPtr;| is invalid syntax.
find . -name '*.cpp' -o -name '*.mm' | xargs sed -i -e '/using nsRefPtr/d'
# RefPtr.h used |byRef| for dealing with COM-style outparams.
# nsRefPtr.h uses |getter_AddRefs|.
# Fixup that mismatch.
find . -name '*.cpp' -o -name '*.h'| \
xargs perl -p -i -e 's/byRef/getter_AddRefs/g'
As part of this move, HOST_NSPR_MDCPUCFG needed to be changed to get the quoting right.
--HG--
extra : commitid : J26MhSiPq9g
extra : rebase_source : 81c5b98371042803741ddace8d01b0097757dff3
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
First we need to set the Gecko thread JNIEnv* in nsAndroidStartup, but
after that we can initialize and deinitialize the rest of JNI, including
AndroidBridge, in GeckoAppShell. This makes nsAppShell control the
AndroidBridge lifetime. Over time, parts of the AndroidBridge
functionality will be migrated to nsAppShell.
When building with MOZ_CRT (which is more or less the default when
building on Windows with MSVC2013), building e.g. XPCOM components
requires linking against mozcrt.lib, so it needs to be shipped in
the SDK. On the other hand, mozglue.lib, which is currently shipped,
is not useful because it lacks the necessary hacks from mozcrt.lib
avoiding crashes for memory allocator mismatch.
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
There is some ambiguity about whether ScheduleComposite will necessarily
trigger a composite all the way to nsWindow::DrawWindowUnderlay. Android
robocop tests assume it will, because they rely on DrawWindowOverlay
being called so they can take a screenshot and make progress,
but this is a very fragile assumption. They also rely on the entire
window being painted, which is also a fragile assumption.
This patch improves the situation by explicitly invalidating the current
window area when Android Java code needs to trigger a composite. This avoids
regressions from future patches in this series which make composition bail
out when there is nothing invalid.
The resulting setup is still a bit fragile for my taste but I'm not sure
what the ideal solution would be.
--HG--
extra : commitid : 3t3xqRdZs24
extra : rebase_source : b23749613663ca805484776ccf5e36b4ff00e3fe
This conversion was done with the script:
find . -name '*.cpp' -o -name '*.h' -o -name '*.mm' -o -name '*.idl' | \
egrep -v 'cairo-win32-refptr.h|RefPtr.h|TestRefPtr.cpp' | \
xargs sed -i -e 's/mozilla::TemporaryRef</already_AddRefed</g' \
-e 's/TemporaryRef</already_AddRefed</g'
Manual fixups were performed in the following instances:
- We handled mfbt/RefPtr.h manually so as to not convert TemporaryRef itself
into already_AddRefed.
- The following files had explicit Move() calls added to make up for the lack
of a copy constructor on already_AddRefed:
dom/base/ImageEncoder.cpp
dom/media/MediaTaskQueue.{h,cpp}
dom/media/webaudio/PannerNode.cpp
- A redundant overload for MediaTaskQueue::Dispatch was deleted.
- A few manual fixups were required in mfbt/tests/TestRefPtr.cpp.
- Comments, using declarations, and forward declarations relating to
TemporaryRef in dom/canvas/ and gfx/layers/ were changed to refer to
already_AddRefed.
Bug 1168719 added a generic replace malloc library which name happened to be
the same as the existing dummy library used to link replace malloc on OSX.
Change the name of that dummy library.
Having this implicit conversion means that we can silently do extra
refcounting when it's completely unnecessary. It's also an obstacle to
making RefPtr more nsRefPtr-like, so let's get rid of it.
NO_INSTALL_IMPORT_LIBRARY is only used in one place, and since we don't even
use $(DIST)/lib for gecko, it actually doesn't make a difference presently.
JS_STANDALONE builds don't need everything in mozglue; have mozglue omit the
unneeded code for such builds.
Since the SpiderMonkey binaries are now more like the other Gecko binaries, we
can remove some special cases for JS_STANDALONE in GeckoSharedLibrary,
GeckoProgram, etc. All Gecko binaries now use mozglue, which contains mfbt, so
we no longer need mention mfbt explicitly.
Add a property to the getBuildConfiguration testing function's result that
indicates whether we're using jemalloc or not.
Include the newly necessary source directories in the SpiderMonkey source
package.
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 allows to resolve weak symbols from some Android device's libc that
dlsym() won't. This is effectively an alternative fix to bug 791419, without
requiring wrapping symbols.
The new class is kind of like SystemElf, but using our linker's own symbol
resolution. This also adds some initialization from ELF program headers that
weren't done previously for self_elf, as well as registration as for CustomElf
instances.
When a library fails to load with CustomElf before it's registered, the
unregistration that does happen in CustomElf's destructor uses link_map,
so it needs to be initialized.
With bug 1077366, the linker makes the library containing it a fake
LD_PRELOAD. As a consequence, instead of, in the linker itself,
explicitely special-casing the symbols that disappeared in Android 4.4
that the flash plugin uses, it is now possible to use normal symbol
resolution to stubs defined separately in libmozglue.
Since essentially everything is linked to libmozglue and libmozglue takes
precedence in symbol resolution in our dynamic linker, there is no need
to wrap most symbols. PR_GetEnv/PR_SetEnv still needs wrapping because
there's no other way to actually wrap the calls from NSPR itself and NSS,
as well as the symbols wrapped because our dynamic linker can't find them
in system libraries on some devices because they're weak.
In order to avoid adding more dlsym overhead than there already is, resolve
symbols directly in the library containing the linker. (GetSymbolPtr is
essentially free ; dlsym makes the system linker compule a ElfHash itself,
and that's quite expensive to do on all symbols)
This also paves the way for direct symbol resolution in all system libraries.
It's necessary to delay it because for the second part, we need to call dlopen,
and until recently bionic's linker dead-locked when using dlopen from a static
initializer.
Android L added a libsigchain library it LD_PRELOADs. That library exposes
a different sigaction than libc's. It's used for ART.
faulty.lib gets its sigaction from libsigchain, but after bug 874708, the
libraries it loads simply use libc's sigaction, assuming it would be the
hooked one. In turn, this means libraries loaded by faulty.lib may
override faulty.lib's handler, which is definitely not the intent.
This essentially restores some of the code that bug 874708 removed.
An alternative fix would be to add support for LD_PRELOAD, but that has more
implications and feels more risky. This could be done, if necessary, as a
followup.
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.
