Entries in kSTSPreloadList currently look like:
class nsSTSPreload
{
public:
const char *mHost;
const bool mIncludeSubdomains;
};
This is inefficient for a couple of reasons:
* The structure has a bunch of wasted space: it takes 8 bytes on 32-bit
platforms and 16 bytes on 64-bit platforms, even though it only uses 5
and 9 bytes, respectively.
* The |const char*| requires additional space in the form of relocations
(at least on Linux/Android), which doubles the space cost of
individual entries. (The space cost of the relocations is mitigated
somewhat on Linux and Android because of elfhack, but there's still
extra cost in the on-disk format and during the load of libxul to
process those relocations.)
* The relocations the structure requires means that the data in it can't
be shared between processes, which is important for e10s with multiple
content processes.
We can make it more efficient by structuring it like so:
static const char kSTSPreloadHosts[] = {
// One giant character array containing the hosts, in order:
// "example.com\0example.org\0example.test\0..."
// Use an array rather than a literal string due to compiler limitations.
};
struct nsSTSPreload
{
// An index into kSTSPreloadHosts for the hostname.
uint32_t mHostIndex: 31;
// We use the same datatype for both members so that MSVC will pack
// the bitfields into a single uint32_t.
uint32_t mIncludeSubdomains: 1;
};
nsSTSPreload now has no wasted space and is significantly smaller,
especially on 64-bit platforms (saves ~29K on 32-bit platforms and ~85K
on 64-bit platforms). This organization does add a couple extra
operations to searching for preload list entries, depending on your
platform, but the space savings make it worth it.
The main loop of |output| tweaks entries, filters out entries based on
some conditions, and writes out the actual entries we're going to use.
Let's separate those three steps so it's clearer what's happening where.
The reason the "checking" string always appears is that @depends
functions are always called, regardless of the value of the dependency.
This introduces a new decorator @depends_true, which works like
@depends, but the decorated function is not called unless one of the
dependency value resolves to True.
The new decorator can also be used to replace many cases where we do
@depends(foo)
def bar(foo):
if foo:
...
Before, virtualenv.py may have attempted to use 3rd party
(untrusted) pip indices when installing wheels for pip,
setuptools, and wheel. These dependencies are vendored in
the tree for a reason. So don't let virtualenv contact the
outside world.
MozReview-Commit-ID: 6BCU0WegJO1
--HG--
extra : rebase_source : 6231235486e8cfa784e67e8b18004dd63d8aaf36
While we're addressing virtualenv foo, let's ensure we are running
the latest version. This also pulls in newer versions of pip (8.1.1),
setuptools (20.3), and wheel (0.29.0).
MozReview-Commit-ID: G5uSy66Kd6u
--HG--
extra : rebase_source : 804f230adcf77335c79a93537d9623ac3836d9bf
This makes "display: -webkit-box" & "display: -webkit-inline-box" into bona
fide "display" values (instead of just aliases), when webkit prefix support is
enabled, and allows us to actually exercise the code added in the earlier
patches on this bug. (Note that when webkit prefix support is *disabled*, our
CSS Unprefixing Service strategy will instead have an opportunity to take
effect, for whitelisted sites, and it'll continue to convert "-webkit-box" to
"flex".)
MozReview-Commit-ID: BV93xs4ddbK
These new enum values are added with same behavior as their modern flexbox
equivalents -- they're hooked up to NS_NewFlexContainerFrame, and they're
listed alongside the modern flexbox enums in 'switch' & 'if' statements.
There's one exception, which I call out with a comment at the end of the patch:
we don't treat -webkit-box the same as flexbox in IsFlexOrGridDisplayType(),
because that method is used to determine whether we should blockify
inline-level children of a flex/grid container, and we don't want to blockify
any children of a -webkit-box. (Instead, we want to wrap them in an anonymous
flex item. That happens in the next patch.)
MozReview-Commit-ID: 9BB4Ib2KpvE
This commit switches Windows builds from Visual Studio 2013
to Visual Studio 2015 Update 1.
Previously, Visual Studio was installed on the builders as part
of the base system image. Starting with this commit, we obtain
Visual Studio from a pre-generated, self-contained archive
containing the executables, Windows SDK, and other support
files. This means that new Windows toolchains can be installed
without having to modify configuration of machines in automation!
The mozconfigs for Visual Studio 2015 are a bit different from
existing mozconfigs.
Because it appears to be completely redundant and not necessary,
the LIBPATH variable has been dropped.
The order of paths in PATH, LIB, and INCLUDE has changed. The new
order more accurately reflects what would be defined by
vcvarsall.bat.
As part of switching to Visual Studio 2015, the Universal CRT is
now required. So, the 2015 mozconfigs export WIN_UCRT_REDIST_DIR
to define the location to those files.
The switch to Visual Studio 2015 also involves the switch from
the Windows 8.1 SDK to the Windows 10 SDK. However, we still
target an old version of Windows, so this hopefully shouldn't
have any significant fallout.
It's worth noting that switching to Visual Studio 2015 makes
builds - especially PGO builds - significantly faster. Our
PGO build times in automation are ~1 hour faster. Our regular
builds appear to be a few minutes faster.
MozReview-Commit-ID: Pa5GW8V87Q
--HG--
extra : rebase_source : bff4fad17f781d8d21bdb941bdd500955d1e9f08
extra : amend_source : faa3038c290fdf5cdd3e24a45ba2a37490f68c17
extra : source : 56b27306d3257445f70374aa78fc5bd42ef300ce
According to dbaron, the deleted block smells like a workaround for
a compiler bug which no longer reproduces in VS2015. This is the last
bug blocking the landing of VS2015. So remove the apparent workaround.
MozReview-Commit-ID: zsmfFjSOxN
--HG--
extra : rebase_source : e1be788c637b7b60a05e1827411cb5838bb68b35
extra : amend_source : f35410b864f8b23def2c2b4f7468738889a2a7d0
End state is Waldo's original patch, which so far has been the only
version that compiles on VS2015.
MozReview-Commit-ID: FCOaEvMqYB4
--HG--
extra : rebase_source : 2ee6e5ec7578b2dedb2f57a0f6df4ce50e191d98
As B2G has been moved to Tier 3, we are turning phone builds off. Only
nexus-5l-eng, aries-eng and aries-debug remain.
--HG--
extra : rebase_source : a8cb8d4d939d1163e9d681290116b59a1ec85e4d
Modify the congruentTo method of MDiv and MMod opcodes to take into
account signedness, which is necessary for correct code generation.
--HG--
extra : rebase_source : 73037989ae280384c9bb2fd21f5e58243f06da4f
Since the minidump path can be overridden programmatically in the chrome
process, using that path as the base for .extra files won't work since content
is unaware of it.
This patch changes everything to use the temp path when MOZ_CONTENT_SANDBOX is
not defined or when sandboxing is disabled via pref. It also moves the derivation
of the content temp path out of exception context on Windows and Mac, as I
found out that those functions touch the heap.
I also noticed that xpcshell is not sandbox-aware when utilized as a parent
process. I've filed bug 1257098 to take care of that, but this patch includes a
hack for the immediate term.
MozReview-Commit-ID: 3SIB5Nihqxh
--HG--
extra : rebase_source : f4f83c4474f12ececa34e9dda68fc19abc56a899
So far we've simply assumed that the first MPEG Layer 3 frame sync we find is automatically valid. However if the audio data has been improperly cut, parsing might start somewhere in mid-stream, so the first frame sync we hit upon might be a false positive. This naturally leads to problems if we try to check later frame syncs for consistency (same MPEG version, sample rate, etc.) with that first frame sync.
Therefore, this patch changes demuxer initialisation to only accept a frame sync if it is followed by a number of further frame syncs consistent with the initial frame.
