Previously we used a ViewStub to only show the back button for some configurations. Now we
show the button always, so we can get rid of the ViewStub.
--HG--
extra : commitid : EcIVAzNG08l
extra : rebase_source : 4bf70217fee2c8913a8343da1bf579b183c81693
The Bluedroid configuration header for B2G is now located in the repo
of libhardware_moz, as Bluedroid drivers should not depend on Gecko's
source code. This patch removes the configuration header from Gecko.
DONTBUILD NPOTB
This has always been possible with Gradle -- Gradle doesn't care where
in the file tree resources are found. (Gradle is perfectly happy to
take resources from outside of the root project directory.) IntelliJ,
however, displays resources outside of known "content roots" in
special and frankly unhelpful ways. Here, we avoid that on a
technicality: IntelliJ doesn't acknowledge (or even register a content
root!) for the non-standard AndroidManifest.xml locations set in
build.gradle. This means we don't see odd content roots in unexpected
places in IntelliJ.
With this change, the formerly failing command
mach clobber && mach configure && mach gradle-install
completes successfully. That gets us one step closer to being able to
open Fennec in IntelliJ without running additional commands.
--HG--
extra : commitid : 6KuAzJIpq3Y
extra : rebase_source : 0b85181412d86fa49ee52cf7d612dd3c4028dfb6
extra : histedit_source : 6b8d8171810501a0af053df080b336af70c456b6
DONTBUILD NPOTB
This needed the same dependency changes that the previous part did.
There's a nice simplification here because some of the code is now
being compiled in the containing project (base) and not the (now
removed) sibling project.
--HG--
extra : commitid : IHKXiR8SpLr
extra : rebase_source : 0b2e03f0a76ed17782f0bbaba61adbfa547a6ba2
extra : histedit_source : 0c3420152b2c37dfcbb6e11e6ca58e6c03ad7aca
While testing, I found some issues with the existing dependencies. To
address them, I've made all project preBuild tasks depend on the
(single) root generateCodeAndResources; this should ensure that the
Make integration happens as early as possible. In addition, I fixed
the dependencies syncing the generated resources into the build
directory, which weren't quite right. This works well locally now.
--HG--
extra : commitid : 4Kblf9h0yst
extra : rebase_source : e9e6fa415939f2622a7cfc09f5945e31269338e4
extra : histedit_source : 4cdf1470a0d99b1f805a4fda69d57f425f613421
Technically, branding should be part of the App and not GeckoView, but
we don't have separated resources yet, so in it goes.
--HG--
extra : commitid : 5r00T6BTBRE
extra : rebase_source : ca1411809bb5352617814bc136689d77358fd29c
extra : histedit_source : a435587e3bf16ad3f5457936a0e4efeffa69f9a4
We were both lazy and incomplete before. Lazy because .aapt.deps is a
sentinel, and doesn't necessarily see relevant changes, due to
timestamps and deletions. Incomplete because we never forced
generated Java code to be fresh.
--HG--
extra : commitid : JXLe9uWqjhN
extra : rebase_source : 8eaa2d012915ad59d5cd03d7e4a6552ae4db13c1
extra : histedit_source : 231ca7ad88e7965424a8c8a3e80dac68a32980a7
The implemetation of Assembler::actualOffset() is now a no-op in all
targets, and it is no longer necessary to rewrite assembler buffer
offsets to their final form after finishing the assembler buffer.
- Delete Assembler::actualOffset() in all targets.
- Delete AsmJSModule::CodeRange::updateOffsets().
- Delete AsmJSModule::updateCodeOffset().
- Delete AsmJSModule::updateOffsets().
- Delete CodeOffsetLabel::fixup().
- Delete ICEnty::fixupReturnOffset().
- Delete LSafepoint::fixupOffset().
- Delete OsiIndex::fixUpOffset().
- Delete PCMappingEntry::fixupNativeOffset().
Also delete all code calling these functions.
--HG--
extra : rebase_source : ff8a0173560e3368c2960442986da41c0b575e49
The ARM assembler no longer needs to keep track of code offsets for
later translation to 'actual' offsets. The AssemblerBuffer offsets
are directly usable now.
Remove tmpDataRelocations_, tmpPreBarriers_, and tmpJumpRelocations_.
--HG--
extra : rebase_source : c07b5a000fa94bb1bbc4220add1af7cd8cbaf22e
The ARM64 assembler no longer needs to keep track of code offsets for
later translation to 'final' offsets. The AssemblerBuffer offsets are
directly usable now.
Remove tmpDataRelocations_, tmpPreBarriers_, tmpJumpRelocations_, and
the finalOffset() method.
--HG--
extra : rebase_source : 52e73f091b1e63970b9fb37b9c22453b0b37910f
This method was used by the Assembler::actualOffset() methods to
translate buffer offsets from pre-pool to post-pool numbers. Since
pools are now injected immediately, there is no need to translate
offsets.
All the actualOffset() methods have become no-ops in all our supported
targets.
--HG--
extra : rebase_source : 7985a847bad5bfde2b696e1ff81420aa981d426c
This is possible because we no longer PodCopy the pools.
Use a more reasonable size for the inline memory in the loadOffsets
vector (8 loads instead of 512). This saves stack space when a
MacroAssembler is created on the stack. Use a matching inline size of 8
entries for the poolData array itself.
Don't drop memory in Pool::reset() by calling placement new - call
Vector::clear() instead which hangs on to previously allocated memory
for use by the next pool.
Delete an unused array of pools in arm64/vixl/MozBaseAssembler-vixl.h.
--HG--
extra : rebase_source : 5bf8228d04b7014934dbc4a4dd035b9508910cb8
Use a Vector with 8 preallocated slots and a LifoAllocPolicy allocating
from the parent AssemblerBuffer's lifoAlloc_. We'll rarely need more
than 8 constant pools in a single assembler.
We can't actually allocate memory from this->lifoAlloc_ in the
constructor, but it is OK to capture allocator references like the
Vector constructor does.
Add an assertion to initWithAllocator() to verify that we didn't
allocate anything from lifoAlloc_ before the MacroAssembler constructor
had a chance to install an AutoJitContextAlloc.
--HG--
extra : rebase_source : 13fd97a76f2fbf318b0c30532a0f5f9ebb024a91
There is no longer a 1-1 correspondence between buffer slices and
constant pools. We no longer need the ability to truncate a buffer
slice prematurely.
This uses less memory.
--HG--
extra : rebase_source : 11fb7941d197991201f9c064f54de5d3078b53bc
Since constant pools have been simplified such that they always follow
the load instructions referencing them, it is now possible to copy the
pool data into the main assembly buffer right away in finishPool()
instead of deferring the copy to executableCopy(). This has the
important effect that BufferOffset values don't need to be adjusted to
account for the size of injected constant pools.
- In finishPool(), copy the constant pool data into the main assembler
buffer with putBytesLarge() which allows the potentially large pool
data to be split over multiple slices.
- Stop copying pool data in executableCopy(). It has already
been copied in finishPool().
- Simplify the PoolInfo data structure to a simple (firstEntry, offset)
pair which records the necessary information about a single emitted
constant pool.
- Rewrite poolEntryOffset() to use the new PoolInfo data.
- Simplify poolSizeBefore() to just return 0. This function will be
removed entirely in a followup patch.
- Stop patching branches in executableCopy() and delete the
patchBranch() method. Since buffer offsets are reliable when the
branches are inserted and when labels are bound, there is no need to
adjust branches to account for constant pools.
- Delete the BufferSliceTail class. It is no longer necessary to
maintain a bit vector of branch instructions since we don't rewrite
branches any longer. Use the plain AssemblerBuffer::Slice class
instead.
This patch implements the basic functional change of copying pool data
immediately instead of deferring it. Followup patches will clean up the
now redundant code.
--HG--
extra : rebase_source : 719225aef25dbf1b4bb7561391224b3c5f8793a5
This new method copies a large amount of data into the assembler
buffer, potentially splitting it across multiple slices.
The existing putBytes() method can only copy into a single slice which
limits the maximum since of data that can be inserted and potentially
wastes space at the end of the previous slice.
--HG--
extra : rebase_source : aab678bd50e232a328748232ca039da7d063639a
This allows us from a child frame to go up one level. This is documented
at http://w3c.github.io/webdriver/webdriver-spec.html#switch-to-parent-frame
--HG--
extra : commitid : GtXAxWLM61v
extra : rebase_source : 9b18d51a5dbefb4dad1cb39b229dc3d55cfae26a
extra : histedit_source : d0a0479e0c9946f242efd71e722685447ae48fd1
The logging interface is moved to xpcom/base, a LogModule wrapper for PR_Log is
added, a thread-safe LogModuleManager is added, and a LazyLogModule class used
to lazily load log modules in a thread-safe manner is added.
--HG--
rename : xpcom/glue/Logging.h => xpcom/base/Logging.h
extra : rebase_source : 89b76664d9477e2c894448cdea4dae1c61f8ca24
This backs out all of the patch except that it retains some of the
comment changes for nsStyleContext::mBits.
--HG--
extra : commitid : 9mBuaxmSDjX
extra : rebase_source : 57935f302f350331f46f98dac86f8f833264c5da
This requires a little bit of gymnastics since it has to add the inverse
of tests, since the is-a-reset-struct tests originally added in patch 8
were made unconditional in patch 9, and with this backout we now want to
execute the code only for inherited structs.
This also doesn't back out the cleanup to use NS_STYLE_INHERIT_BIT() for
constants rather than nsCachedStyleData::GetBitForSID.
This backs out the part of bug 1209603 whose speed I was concerned about.
--HG--
extra : commitid : 6BWdXCpywlU
extra : rebase_source : 15597857a721a3a399432c8454ecfc7b789e5e2d
This leaves the half related to inherited structs, since we can still
bail early for them even without mBits.
--HG--
extra : commitid : 28h25awejXa
extra : rebase_source : 9b92da7d25fc2963c33cab063bca4fef4388a816
