- Adding an array member to access the components of vector, size,
and matrix classes reduces the code needed when passing all of the
members to functions.
MozReview-Commit-ID: A6XL7y3zwsV
--HG--
extra : rebase_source : 77fb1b9784ae1213530cff7f42563e0afc8859e3
When using GetIIDForParamNoAlloc to get return paramter type, if param is nsIDOM*, it should get it by GetShimForParam.
When this situation, GetEntryFor Param tries to get nsIDOMDocument, so GetEntryForParam doesn't get entry. Then, GetShimForParam tries to get entry. But since it doesn't traverse parent objects, it will try to get nsIDocShell instead.
So it might not get correct entry.
MozReview-Commit-ID: LaOVymgFMgi
--HG--
extra : rebase_source : 9ce3b38872dd6bcabd473296cc5bda25c7d5ceab
extra : histedit_source : 385797913a2d76e2981b4106d572edd784145126
This patch implements mozilla::NotNull, which is similar but not identicial to
gsl::not_null.
The current draft(?) implementation of gsl::not_null is at
https://github.com/Microsoft/GSL/blob/master/include/gsl.h.
The main difference is that not_null allows implicit conversion from T to
not_null<T>. In contrast, NotNull only allows explicit conversion from T to
NotNull<T> via WrapNotNull().
The rationale for this is that when converting from a less-constrained type to
a more constrained type, implicit conversion is undesirable. For example, if I
changed a function f from this:
f(int* aPtr);
to this:
f(gsl::not_null<int*> aPtr);
no call sites would have to be modified. But if I changed it to this:
f(mozilla::NotNull<int*> aPtr);
call sites *would* need to be modified. This is a good thing! It forces the
author to audit the call sites for non-nullness, and encourages them to
back-propagate NotNull throughout the code.
The other difference between not_null and NotNull is that not_null disables
pointer arithmetic, which means it cannot be used with array pointers. I have
not implemented this restriction for NotNull because it seems arbitrary and
unnecessary.
I don't think anyone is using this anymore. It would be good to assert that there
are no leaks, but that doesn't pass for me in a local build, and I don't have time
to chase it.
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
