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
MOZ_SOURCE_REPO is set by automation to indicate the URL of the current
repository. I'm not sure what SRCSRV_ROOT is from. Probably legacy.
Use MOZ_SOURCE_REPO instead of SRCSRV_ROOT.
MozReview-Commit-ID: IfCSiaqgJb5
--HG--
extra : rebase_source : a3877173837cdd9217ea2a8a1dac66db0b2b9988
Currently an inlined function in a namespace in DWARF will
be given a name comprised of just `namespace::`. This is due
to a logic error in ComputeQualifiedName, where it doesn't
handle an empty `unqualified_name` properly.
We apparently have a fair number of these in our Mac builds,
an example of the DWARF that's being mishandled looks like:
0x117eda40: TAG_namespace [5] *
AT_name( "js" )
AT_decl_file( "../../dist/include/js/Utility.h" )
AT_decl_line( 35 )
0x11808500: TAG_subprogram [251] *
AT_low_pc( 0x0000000002f12110 )
AT_high_pc( 0x0000000002f1216b )
AT_APPLE_omit_frame_ptr( 0x01 )
AT_frame_base( rsp )
AT_abstract_origin( {0x0000000011800a4f}"_ZN2js40TraceManuallyBarrieredGenericPointerEdgeEP8JSTracerPPNS_2gc4CellEPKc" )
AT_MIPS_linkage_name( "_ZN2js40TraceManuallyBarrieredGenericPointerEdgeEP8JSTracerPPNS_2gc4CellEPKc" )
AT_name( "TraceManuallyBarrieredGenericPointerEdge" )
AT_decl_file( "/builds/slave/rel-m-rel-m64_bld-000000000000/build/js/src/gc/Marking.cpp" )
AT_decl_line( 547 )
AT_external( 0x01 )
AT_APPLE_optimized( 0x01 )
AT_inline( DW_INL_inlined )
This turned a few instances of this in the file I was testing on into
`<name omitted>`, which seems to just be a symptom of the
"DW_AT_abstract_origin comes later in the file" issue. (Which is probably
also worth fixing given that it occurs some 29k times when dumping
symbols from Firefox's XUL binary, but it's a separate issue.)
R=mark@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1887033002 .
MozReview-Commit-ID: L3cn5z4FY6M
--HG--
extra : rebase_source : 03ebda4cf2d1179b2180a2817137a5f600f7ad1a
This patch unifies the include search directories for the breakpad
on B2G and Android, and protects breakpad-internal workarounds against
multiple definition.
As a side-effect of the patch set, no more Gonk-specific headers from
'gonk-include' are requried to build toolkit/ or xpcom/. The related
artifacts are removed by this patch.
MozReview-Commit-ID: E94I2rspDtJ
This patch unifies the include search directories for the breakpad
on B2G and Android, and protects breakpad-internal workarounds against
multiple definition.
As a side-effect of the patch set, no more Gonk-specific headers from
'gonk-include' are requried to build toolkit/ or xpcom/. The related
artifacts are removed by this patch.
MozReview-Commit-ID: E94I2rspDtJ
These locations have changed since the end of Google Code.
MozReview-Commit-ID: FSGhFBDaTCq
--HG--
extra : rebase_source : 4ef004b2d0b8f1a6331db0f44ccf70d05ad62774
This was causing the "path" argument to get swallowed because makecab.exe
thought it was the argument to /D. Derp.
MozReview-Commit-ID: 6Bd3l7ISsPj
--HG--
extra : rebase_source : fbba4e8aff9a164aa10278de08de67c3f38cdf58
makecab.exe has 3 options for compression: disable, MSZIP, and LZX.
Here is a breakdown of the 3 levels of compression for an opt 32-bit
build on my i7-6700K:
directory size full.zip xul.pd_ `buildsymbols`
None 1,360 MB 227 MB 146 MB 49s
MSZIP 520 MB 221 MB 142 MB 113s
LZX 436 MB 169 MB 102 MB 248s
(The original size of xul.pdb is ~500 MB.)
This commit switches us to MSZIP as the compression format. This
makes `builsymbols` >2x faster while only increasing the full zip
archive size by ~31%. This feels like an appropriate trade-off.
The memory related flag has been removed because it only applies
to LZX compression.
It's worth noting that using `zip` to compress xul.pdb and xul.sym:
Level Zip Size xul.pdb Compressed Time
9 160.6 MB 139.8 MB 76s
7 161.4 MB 140.5 MB 30s
5 164.7 MB 143.2 MB 16s
4 170.0 MB 147.3 MB 12s
3 176.4 MB 151.6 MB 11s
So "MSZIP" compression appears to be using level 9. If we could swap
in our own cab generator that uses a zlib compression level less
than 9, we'll make symbol generation significantly faster without
sacrificing too much size. I'm inclined to punt that to a follow-up
bug.
MozReview-Commit-ID: GbbClkn9PLN
--HG--
extra : rebase_source : 05f94f381a892d82f512b5c3682e51f6735714f3
This patch was generated by the command:
find * -type f -exec sed -i -f ../mozpropsub {} \;
in the root of the repository, with the file ../mozpropsub containing:
s/-moz-padding-end\>/padding-inline-end/g
s/-moz-padding-start\>/padding-inline-start/g
s/-moz-margin-end\>/margin-inline-end/g
s/-moz-margin-start\>/margin-inline-start/g
s/-moz-border-end\>/border-inline-end/g
s/-moz-border-end-color\>/border-inline-end-color/g
s/-moz-border-end-style\>/border-inline-end-style/g
s/-moz-border-end-width\>/border-inline-end-width/g
s/-moz-border-start\>/border-inline-start/g
s/-moz-border-start-color\>/border-inline-start-color/g
s/-moz-border-start-style\>/border-inline-start-style/g
s/-moz-border-start-width\>/border-inline-start-width/g
s/\<MozPaddingEnd\>/paddingInlineEnd/g
s/\<MozPaddingStart\>/paddingInlineStart/g
s/\<MozMarginEnd\>/marginInlineEnd/g
s/\<MozMarginStart\>/marginInlineStart/g
s/\<MozBorderEnd\>/borderInlineEnd/g
s/\<MozBorderEndColor\>/borderInlineEndColor/g
s/\<MozBorderEndStyle\>/borderInlineEndStyle/g
s/\<MozBorderEndWidth\>/borderInlineEndWidth/g
s/\<MozBorderStart\>/borderInlineStart/g
s/\<MozBorderStartColor\>/borderInlineStartColor/g
s/\<MozBorderStartStyle\>/borderInlineStartStyle/g
s/\<MozBorderStartWidth\>/borderInlineStartWidth/g
The diffs for the following files:
layout/style/nsCSSPropAliasList.h
layout/style/test/property_database.js
layout/style/test/test_value_computation.html
were then manually removed from the patch.
MozReview-Commit-ID: 8fbYnlZcn9U
The original changeset that is being backed out had comment:
Bug 1023941 - Part 4: Static-link the CRT into crashreporter.exe.
MozReview-Commit-ID: AWoYiy4TfNW
--HG--
extra : rebase_source : 97dd66786c1d9fbd9374158e703665c371940401
It's possible for `IDiaSymbol::get_name` to return S_OK and provide
and empty string. I haven't figured out the exact root cause yet
(the symbols in question are coming from the Rust standard library),
but FUNC lines with missing function names break the processor and
so we should never do it. This change makes it output "<name omitted>"
which matches the behavior of the DWARF dumping code.
Review URL: https://codereview.chromium.org/1985643004 .
MozReview-Commit-ID: E8jZZM5KVtJ
--HG--
extra : rebase_source : 7236563a7a4bada7c7126cebd24f3551e70919ae
