As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings, of course.
Given that the warning is in WebRTC which is third party code, there
isn't much we can do about the warning. However, Google is building
Chrome with Visual Studio 2015, so I wouldn't be surprised if this
were fixed upstream or will be fixed upstream. Then again, we allow
warnings when building WebRTC. So perhaps not.
MozReview-Commit-ID: G6JP9fkCzfn
--HG--
extra : rebase_source : bf5c9a049230bb8e483f6a85bdbc2ca20eb3ab45
This will make it easier for binaries only archive generation to consult
the list of binaries that are relevant to packaging.
This does overlap somewhat with compile databases. Perhaps someday the
logic could converge.
While I was here, I cleaned up writing of the all-tests.json file to
avoid an intermediate string variable.
This patch adds to_dict methods on some frontend data types. There is
room to improve the serialization of these types. For example, we could
use __slots__ to drive the default formatter. We could also leverage a
custom JSONEncoder class that knows how to call to_dict() on instances.
In the spirit of perfect is the enemy of done, I think this should be
deferred to a follow-up bug.
MozReview-Commit-ID: XVnKB1MNqu
--HG--
extra : rebase_source : 376c93467dde3450c7c21cff918cb34913a3c5fe
Now when we print instances in a debugger, we'll see something like:
<StaticLibrary: other-licenses/snappy/libother-licenses_snappy.a>
<StaticLibrary: toolkit/library/StaticXULComponentsEnd/libStaticXULComponentsEnd.a>
<SharedLibrary: toolkit/library/XUL>
<StaticLibrary: toolkit/library/libxul_s.a>
<HostProgram: config/nsinstall_real>
<Program: memory/replace/logalloc/replay/logalloc-replay>
<SimpleProgram: mfbt/tests/TestArrayUtils>
... instead of the the class name and memory address.
MozReview-Commit-ID: 8zdrM6KfP8U
--HG--
extra : rebase_source : 7f964ad44a0061674f77d5716a6769a4aedb9e6c
While almost identical to video/mp4, quicktime files often use codecs that we don't support: in particular MPEG4 part 2 and amr audio.
If a plugin exists and is enabled, prefer it to handle those files.
We only do so when opening the file directly. Media in <video> element will always play natively.
MozReview-Commit-ID: 1yPpzfDaCfT
--HG--
extra : rebase_source : 4c66eb0fd81a288f4c8eed643c79cf9851bd4273
Splitting Each HuffmanIncomingTable into two parts avoids the wasted
0/nullptr fields and allows the remaining fields to be packed more efficiently.
Making them all const allows them to be shared between processes.
On 64-bit platforms this saves (60*N - 7.5) KiB, where N is the number of
processes.
--HG--
extra : rebase_source : 1c55b325a01df53b0d8e28e5f3102b8ed57e5e47
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. So hopefully
this patch never lands because someone insists of fixing the underlying
problem instead. But if it does land, hopefully the workaround is
only temporary. That being said, the warning occurs in 3rd party ICU
code. So I'm not sure what my options are for fixing this.
MozReview-Commit-ID: 2MIqvI3qCsZ
--HG--
extra : rebase_source : cbb3b14a1e6fd47aeb9e4ce915cddd0b78ce90cf
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. So hopefully
this patch never lands because someone insists of fixing the underlying
problem instead. But if it does land, hopefully the workaround is
only temporary.
MozReview-Commit-ID: 70QwT9y6eb2
--HG--
extra : rebase_source : afc1eb71d11241819a4e2d2219e699c081f0c4af
As part of unblocking building with VS2015u1 in automation, I'm mass
disabling compiler warnings that are turned into errors. This is not
the preferred mechanism to fix compilation warnings. So hopefully
this patch never lands because someone insists of fixing the underlying
problem instead. But if it does land, hopefully the workaround is
only temporary. That being said, the warning occurs in 3rd party ICU
code. So I'm not sure what my options are for fixing this.
MozReview-Commit-ID: 9gOSotjaQsN
--HG--
extra : rebase_source : c1a6c51bcdd4e1a882f371e7beba4f88d5c059a4
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
I'm not sure when this changed, but at least Visual Studio 2015
doesn't always emit a space between the line number and the ": warning"
text in cl.exe output.
Making the space optional in the regular expression enables one a
VS2015 build to capture 375 warnings instead of 17. We still fail to
capture some warnings (notably generic warnings about bad command
arguments and linker warnings). But that can be dealt with later.
MozReview-Commit-ID: q402CxTrQK
--HG--
extra : rebase_source : 6376a65b8d8145d68bad9b795b6abd6f4becefbd
