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
startupcache/StartupCacheUtils.cpp:239:27 [-Wshadow] declaration shadows a local variable
--HG--
extra : rebase_source : 08b7054319e31c8839ffc64e14ddf83430e722b9
The lone remaining startup cache-related uses of nsAutoArrayPtr are both
in TestStartupCache.cpp, for use with nsIStartupCache::GetBuffer. The
uses can't use StartupCache::GetBuffer because StartupCache::GetBuffer
isn't visible outside of libxul, and TestStartupCache is a normal C++
unit test.
The Right Thing is to convert TestStartupCache to a gtest so we can see
libxul internal symbols and then delete nsIStartupCache entirely.
That's a bit complicated, as TestStartupCache doesn't fit nicely into
gtest's framework. The simpler solution is to add a UniquePtr overload
in the interface that hides the XPCOM outparam management details.
Similar to the previous change to NewObjectInputStreamFromBuffer, we
want to make the ownership transfer out of NewBufferFromStorageStream
more obvious. Doing this also lets us get rid of some uses of
nsAutoArrayPtr, which is less idiomatic than UniquePtr.
Because NewObjectInputStreamFromBuffer takes a raw pointer as input, the
typical coding pattern to use it is:
nsAutoArrayPtr<char> buf;
// assign something to buf
nsresult rv = NewObjectInputStreamFromBuffer(buf, ...);
if (NS_FAILED(rv)) {
...
return rv;
}
buf.forget();
Which is clumsy, error-prone, and obscures the ownership transfer of the
pointer into the stream returned by NewObjectInputStreamFromBuffer.
Let's address all of these concerns by changing the argument to a
UniquePtr<char[]>.
TestWriteObject() in TestStartupCache.cpp uses this odd pattern of
acquiring a raw pointer from the startup cache, and then stashing that
raw pointer into an nsAutoArrayPtr. We can do better by using the
getter_Transfers idiom and thereby always using the smart pointer.
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
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
This makes it clearer that, unlike how SizeOf*() functions usually work, this
doesn't measure any children hanging off the array.
And do likewise for nsTObserverArray.
--HG--
extra : rebase_source : 6a8c8d8ffb53ad51b5773afea77126cdd767f149
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
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.
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.
