CacheClientSeek() will call Seek() asynchronously and should be used by MediaCache only.
ChannelMediaResource::Resume() runs on the main thread and can call Seek() directly.
Note this is a missing change from bug 1411504 P3.
MozReview-Commit-ID: I2X1Rk5HoDV
--HG--
extra : rebase_source : 66dce75aefc4bfebecf69ebe107e9b4c9286f3a5
extra : source : 20e5463e15049095a941f501acd3fa7dd4e9b1db
This makes the code nicer. In particular, it removes many getter_Copies()
calls. The patch also converts a lot of nsCStrings to nsAutoCString, which will
avoid heap allocation in the common case.
The patch also renames PREF_CopyCharPref() as PREF_GetCStringPref(), because
it's actually getting a string, not a char, and that matches the existing
GetCString() and GetDefaultCString() methods. Correspondingly, it also renames
PREF_SetCharPref() as PREF_SetCStringPref().
The |aPrefName| arguments in nsIPrefBranch.idl remain as |string| because they
almost always involve passing in C string literals, and passing "foo" is much
nicer than passing NS_LITERAL_CSTRING("foo").
It's worth noting that early versions of this patch used |AUTF8String| instead
of |ACString|. But it turns out that libpref stores prefs internally as Latin1.
And |ACString| is compatible with Latin1 but |AUTF8String| isn't, because
non-ASCII Latin1 strings are not valid UTF-8!
MozReview-Commit-ID: D3f7a1Vl1oE
--HG--
extra : rebase_source : e6e4b15d6d210cfd93686f96400281f02bd1d06b
- Building is nightly channel only. Beta and release for Fennec 58 don't build
stylo. It means that the package size for 58 beta/release isn't incremented
by this change.
- The preference for stylo is still turned off Nightly 58. It will be turned on
59 after fixing some bugs for crashtests and etc. Our target to enable stylo
for Android is 59.
- ./mach bootstrap already installs clang etc to build stylo and bindgen.
Developers for mobile won't require additional build options for this change.
MozReview-Commit-ID: CIpYl8I5d7x
--HG--
extra : rebase_source : 6387704e4a94db080d4add10298cf1cc254ddec0
The earlier patches in this bug were written before we had
sophisticated binding generation so the types didn't match very well.
This fixes all of that.
MozReview-Commit-ID: DpcblpB8vxW
These tests were failing because of some misoptimizations that GCC did.
clang is generating correct code here, and the tests correctly pass, so
we can mark them as such.
NDK r15+ clang changed the code generation strategy for the __atomic_*
intrinics such that using them with 64-bit types now requires linking
with libatomic. Our current configure tests for libatomic doesn't catch
this, because the std::atomic implementation is such that it doesn't
require an external library, even for 64-bit types, whereas the
__atomic_* intrinsics do. The safest thing to do is to force this
configure check to always return true when we are compiling for
x86/Android with clang.
The NDK clang needs to be informed about the existence of a GCC
toolchain, so important programs like the linker can be located. With
this change, we're starting to use command-line options that are
incompatible with GCC, so we also add a check to inform the user about
the non-support for this configuration.
Our normal method of locating the compilers in the NDK is to set
--with-toolchain-prefix when compiling for Android. However, the clang
binaries are in a different location than would otherwise be implied by
--with-toolchain-prefix. Additionally, we still need to know about
--with-toolchain-prefix because the NDK clang needs to be pointed there
so clang can find important binaries like the linker and because various
other bits of the build system depend on the --with-toolchain-prefix
value as well.
So we need a separate mechanism for communicating the whereabouts of the
NDK clang. We can't set CC and CXX because doing so would conflict with
the CC and CXX values exported to the js/src/ subconfigure. But Android
already has an extra_toolchain_flags function that we use for informing
moz.configure about additional flags needed solely for Android, and we
can use a similar trick to communicate the existence of the NDK's clang
to the main C/C++ compiler selection process.
We already dealt with issues around dlsym not resolving weak symbols
with libc in bug 1081034. This fix applies the same workaround to libm,
which solves the isnanf issue.
The previous fix for looking up __isnanf is no longer needed.
