This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This is disabled already in updater-common.build and similar places, so that
they can use UniquePtr and include <new>.
These files were getting around it because they didn't include the stl at all,
but now they include <utility> transitively for std::move.
MozReview-Commit-ID: IaU9mRbbCAk
At this point, all uses of GetPIPNSSBundleString *should* be on the main thread,
so we can just remove the nsINSSComponent version and rely on the
nsNSSCertHelper instance.
MozReview-Commit-ID: Lt7AgokGKRH
--HG--
extra : rebase_source : 95d3cf6e011468e2aa9df9bb69372ac4d3430286
This relies on the fact that providing multiple --version-script
combines them all, so we effectively create a new symbol version
that has no global symbol, but hides as much std::* stuff as possible.
The added symbol script could use `extern "C++"` syntax and demangled
symbols but there is no guarantee the demangled symbols won't change.
Plus, it's not possible to match demangled symbols that have a return
type: they contain a space, and the only way to match that is to use
double quotes, which doesn't allow globs at the same time.
This version script trick happens to work with BFD ld, gold, and lld.
The downside is that when providing multiple --version-script's, ld
doesn't want any of them to have no version at all. So for the libraries
that do already have a version script (through SYMBOLS_FILE), we use a
version where there used to be none, using the library name as the
version. Practically speaking, this binds the libraries a little closer
than they used to be, kind of non-flat namespace on OSX (which is the
default there), meaning the dynamic linker will actively want to use
symbols from those libraries instead of a system library that might
happen to have the same symbol name.
--HG--
extra : rebase_source : 78adb64b90e75ebad203b8a647b305c9d7198d16
Implemented Rust/C++ glue code for rtcp-fb
Implemented parsing support for rtcpfb-wildcard in rust
Activated c++ unit tests
MozReview-Commit-ID: 5xRSQz7pucZ
--HG--
extra : rebase_source : 97fdfda9134197381d16e0a61dda5357bba9e9da
Some of the RDM toolbar icons relied on `background-size: cover` from the
overall DevTools button styles, which was removed recently in bug 1442531. We
restore RDM's appearance by copying this style into RDM styles.
MozReview-Commit-ID: KcZwaRgZUsh
--HG--
extra : rebase_source : 4a2f548f6f073870ad06183a33bdaabc2bff6d92
This patch will apply the grid layout to the toolbar.
If devtools's width is narrow, we expected that devtool display chevron and the
controls elements only(i.e. chevron and meatball and close button).
In order to display these button, a wrapper of toolbar will use grid layout.
Basically, this patch define grid columns as follow:
------------------------------------------------
| Picker | tooltabs | commands | controls |
| auto | 26px ~ 1fr | auto | max-content|
------------------------------------------------
We can disable the picker and command buttons, in this case, a toolbar will
stretch the tooltabs width by using grid-column-start/end.
MozReview-Commit-ID: ByY2qt2xhAg
--HG--
extra : rebase_source : c86b30acbfc32172eceea365e84ed03d717d5345
This patch will allow that all buttons which accessing the tool panel is
overflowed. i.e. toolbar will display chevron button only.
MozReview-Commit-ID: GbKbAhtpYt7
--HG--
extra : rebase_source : 971aef121c329e6a5ba3ada24015a1d820aab26a
This patch will two impprove performances:
* Remove unnecesarry reflow by using the DOMWindowUtils.getBoundsWithoutFlushing().
This is a tiny performance improvement. Previous code will reflow on each
tab width caclculation.
* Change requestIdleCallback's timeout to 100ms.
If user resize the devtool's width over time, overflow calculation will occur
every 300ms. This patch will reduce this delay.
MozReview-Commit-ID: FxZuK0wGxHk
--HG--
extra : rebase_source : 06a0a4ba5312125e7d15378c253f7278a39a69f9
If we're running on Valgrind, we'll be making forward progress at a rate of
somewhere between 1/25th and 1/50th of normal. This can cause shutdown
timeouts frequently enough to be a problem for the Valgrind runs on
automation. As an attempt to avoid the worst of this, this patch scales up
the presented timeout by a factor of three. For a non-Valgrind-enabled
build, or for an enabled build which isn't running on Valgrind, the timeout
is unchanged.
--HG--
extra : rebase_source : 7c2c51f65137805a34ededc241eb04708fae15a6
