rust-bindgen will make an enum variant for the first definition it encounters,
and then define duplicates as constants outside of the enum definition. This has
the unfortunate effect of making AsmJSCache_MIN an enum variant and
AsmJSCache_Success the constant definition outside of the enum in the case of
the AsmJSCacheResult enumeration. This commit rectifies that.
This upstreams the following commit from servo/mozjs:
50f47cf Bind AsmJSCache_Success rather than AsmJSCache_MIN
With more recent version of ASAN, the updater program shows multiple
leaks, for different reasons.
One is that the updater code heavily relies on pointers into a large
buffer, with exceptions, making things difficult to avoid leaks of those
exceptions. At least it requires more effort than I'm willing to put for
the sake of upgrading the compiler we use for ASAN.
Another is that the leak suppressions are not currently used for
xpcshell tests, and some leaks attributed to libglib, that would
normally be suppressed, are not.
Moreover, even if the suppressions were used, it looks like some are not
rooted to already suppressed system libraries, and would require
investigation. Ideally, we'd have debug symbols installed for the system
libraries and would have full stack traces, but we don't, so this makes
the whole process harder than necessary.
All in all, the updater is a separate short-lived program, and until we
can address all the problems above, we can just ignore memory leaks in
it (which aren't new anyways and are ignored by not being detected by
the ASAN currently used on automation). We don't disable ASAN entirely,
though, only leak detection, and only for the updater program.
Build slaves on automation are based on Centos 6, which doesn't have a
recent enough version of libstdc++ for our new requirements. But since
we're building with a recent GCC or clang with its own libstdc++, we do
have such a libstdc++ available somewhere, and the compiler picks it
when invoking the linker.
Problems start happening when we execute some of the built programs
during the build, like host tools (e.g. nsinstall), or target programs
(xpcshell, during packaging). In that case, we need the compiler's
libstdc++ to be used. Which required adding the GCC or clang library
directory to LD_LIBRARY_PATH.
Unconveniently enough, the clang 3.5 tooltool package we're using for
ASAN builds until we can update to at least 3.8 (bug 1278718) doesn't
contain libstdc++.so. So for those builds, pull the GCC package from
tooltool as well, and pick libstdc++ from there.
Similarly to the considerations about glibc, the Linux compatibility matrix
(https://developer.mozilla.org/en-US/Firefox/Linux_compatibility_matrix)
tells us no distro with Gtk+3 3.4 has a version of libstdc++ older than
4.6.
The data in the matrix doesn't go to that level of detail, but Ubuntu
12.04 LTS, being the only one with version 4.6 (others have at least
4.7), it's worth noting it has version 4.6.3. Which means we can safely
require libstdc++ symbols version 3.4.16 (which were added in 4.6.1).
This will allow us to remove a lot of the stdc++ compatibility hacks.
The requirement for glibc has been set to version 2.7 for a long while.
Spidermonkey uses the pthread_setname_np symbol, which is only available
since glibc 2.12. So far, we've been fortunate that the symbol doesn't
end up in libxul, or tests that link to js directly, because the symbol
is eliminated as being called by effectively dead code.
There are multiple reasons why this is going to change, one of which
being changes to the way things are linked, that will make the linker
not eliminate that code in some cases. Another is that eventually, the
separation of build systems between js and top-level is going to fade,
and the glibc checks, which apply to all gecko binaries, will also apply
to js binaries. They currently are not happening, and would fail because
of pthread_setname_np if they were.
Taking a step back, as of version 46, the mozilla.org builds require at
least Gtk+3 3.4. Which means the requirements for the underlying system
have received a dramatic bump, and it's time to revisit the requirements
for binary compatibility.
I went through all my notes from all the recent times binary compatibility
has been considered, and put together a compatibility matrix on MDN from
that data as well as more recent data that I could find here and there,
about the major non-rolling-release distros (RHEL, Fedora, SuSE, Debian,
Ubuntu)
https://developer.mozilla.org/en-US/Firefox/Linux_compatibility_matrix
Considering the data there, none of the distros that have at least Gtk+3
3.4 have a glibc older than 2.13. The list of symbols that 2.13 provides
that 2.12 doesn't have is not large enough, though, to really care about
depending on 2.13.
This patch defines two constants kSelectionTypeCount and kPresentSelectionTypeCount. The former is same as nsISelectionController::NUM_SELECTIONTYPES. The latter is kSelectionTypeCount - 1 for excluding SELECTION_NONE. The latter is useful in some loops which handle all selection types except SELECTION_NONE.
Note that this patch fixes a bug of nsFrameSelection. That doesn't treat SELECTION_NONE as a selection (see the definition of index), however, it defines redundant item and doesn't use it actually. Additionally, it computes invalid selection type in each loop. Therefore, without this patch, debug build hits MOZ_ASSERT() in ToSelectionType(RawSelectionType).
Note that these constants are defined as anonymous enum because we cannot define as const (or static) even with extern. If we'd try to do it, it caused link error or not available in nsFrameSelection.cpp as constant value since they were not initialized if they were initialized in nsSelection.cpp. Therefore, these constants are defined as enum items but using "k" prefix.
MozReview-Commit-ID: H6sH7NBEXlE
--HG--
extra : rebase_source : fd517d5fc2e2d5dc2f96313e2802fd1719817af7
This patch defines mozilla::SelectionType as an enum class. This is safer than nsISelectionController::SELECTION_* since setting illegal value to its variable is checked at build time. So, as far as possible, this should be used everywhere (but of course, this isn't available in scriptable interfaces).
And also this implements some useful methods for managing SelectionType and RawSelectionType which are implemented in layout/nsSelection.cpp because nsISelectionController is implemented by both PresShell and nsTextEditorState. Therefore, implementing one of them may make hard to find them. On the other hand, nsSelection.cpp is a better file name to look for them.
Note that this patch creates mozilla::Selection::RawType() for binding. Native code should keep using Selection::Type() but the binding code needs to use RawType() due to impossible to convert from SelectionType to RawSelectionType without explicit cast.
MozReview-Commit-ID: 81vX7A0hHQN
--HG--
extra : rebase_source : d9f88e217c713c60d1c2578ce6421c73ccba8650
A listener was added for stylesheet changes only if the stylesheet already
contributed to the page before the modification. So if there was a stylesheet
without any rule matching a node of the page, when a rule was created in it for
the current selected node in the markup view, the rule view wasn't refreshed.
The fix here is to emit an event, from the TabActor, when a StyleSheetActor is created,
and listen to such event to watch for changes in it, in order to update the rule view.
Modify an existing rule view/stylesheet editor sync test to make sure this bug is fixed.
MozReview-Commit-ID: H3szbUnchQP
--HG--
extra : transplant_source : %F7%E0%D2%8B%B3%D2%C3%1F%F8%88%03%AA%10Q%E4%B8h%0C%BE_
This patch converts the inspector's context menu implementation away from
directly using XUL menus, and updates a number of tests to match.
MozReview-Commit-ID: L8aL23BUmXS
Nick Fitzgerald
Andrea Marchesini
Mike Hommey
Carsten "Tomcat" Book
Gabriele Svelto
Saad Quadri
Thauã Silveira
Kevin Lam
Jonathan Kingston
Nicholas Nethercote
Masayuki Nakano
Nicolas Chevobbe
Drew Willcoxon
Phil Ringnalda
Brian Grinstead
Andrzej Hunt
Panos Astithas
Julian Descottes
J. Ryan Stinnett
Dão Gottwald
Gijs Kruitbosch
Justin Wood