Back when this was added, there was an incentive to try to build
gkrust-gtest before gkrust so that libxul-gtest could have a chance
to link and be dumpsymbol'ed while gkrust compiles.
While we may still want that to happen to some degree, the way it's done
right now, with how things evolved over the years, ends up being
counterproductive and ends up delaying all the rust compiles entirely.
We'll deal with improving the overall ordering of builds in bug 1651293.
(This only affects CI)
Differential Revision: https://phabricator.services.mozilla.com/D192015
This change introduces the possibility for more interdependencies being
recorded automatically, but making this work reliably more generally
we'll probably need more work, so at the moment, just make it work for
wasm2c.
Differential Revision: https://phabricator.services.mozilla.com/D191925
There are unfortunate cases where all the rust targets don't end up on
the same line, and that's kind of confusing.
This keeps the rust targets using "Rust" (in config/makefiles/rust.mk)
and switching individual crates to "RustCrate". They will still appear
close to each other in the profiles, but targets will now have their
dedicated line.
Differential Revision: https://phabricator.services.mozilla.com/D192013
At the top-level, what we currently have is something akin to:
export: some deps
echo BUILDSTATUS TIER_START export
make recurse_export
...
In practice, what this means is that `some` and `deps` are built outside
the export tier/phase.
Since recurse_export is itself a recipe with dependencies, we can "just"
move `some` and `deps` to become dependencies of recurse_export instead.
But since in non top-level directories, recurse_export is not a thing,
we still need to keep the dependencies on export there.
Unfortunately, we have one instance of something built during
recurse_export that relied on its undeclared/undeclarable dependencies
being built before recurse_export, so we need to accomodate for that.
Also, for some reason, recurse_pre-export was a two-colons recipe, while
the other recurse_* recipes were single-colon, so fix that.
Come to think of it, the same probably applies to misc and libs, which
this would mechanically fix alongside.
Incidentally, this also makes those things that ran before recurse_* run
in parallel of the other things that run during recurse_*.
Differential Revision: https://phabricator.services.mozilla.com/D191913
$? will only pass the dependencies that have triggered the command to be
called, which will save some work in rebuild_check. However, since
rebuild_check does the difference between removed and modified files,
it still needs to keep checking files.
But, the real reason we need this check is that gkrust.d can have
dependencies with spaces in them, and Make special variables like $^ or
$? don't handle those nicely, and while those files with spaces in
them are most likely unchanged (in most cases, they are going to be
files from the Windows SDK), they end up always reported as the cause
for rebuilds when setting REBUILD_CHECK. $? is more likely not to
contain files with spaces.
Differential Revision: https://phabricator.services.mozilla.com/D191381
Because the force-cargo-* rules don't have actual dependencies, the
REPORT_BUILD call can't usefully report why cargo is invoked when
setting REBUILD_CHECK.
This also has the side effect of making the non-verbose output nicer
(containing the actual built file rather than force-cargo-*)
Differential Revision: https://phabricator.services.mozilla.com/D191380
There are subtle differences in the two implementations that actually
make the variant for RUST_PROGRAMS not work currently:
- there is a %.h leftover from bug 1855623
- there is a missing $(basename) when trying to find the .d file,
preventing it from being found.
With a common rule, we avoid such subtle differences, and that also
allows to further implement fixes without missing one of the cases.
This will also allow to add the same trick to other rules, which should
already have it.
Differential Revision: https://phabricator.services.mozilla.com/D191378
MinGW can't find the header <shobjidl_core.h>... but also doesn't need
to, since it's implicitly included by <shobjidl.h>.
Differential Revision: https://phabricator.services.mozilla.com/D192022
The functions return a reference to a value that is normally protected
by a lock in an unlocked manner, but they do so on purpose.
One of them can be annotated with the lock that is being held when it's
called, though, so we do that.
Differential Revision: https://phabricator.services.mozilla.com/D191707
This fixes an issue where the restore/save patch-stack scripts change the Windows(CRLF)
line endings to Linux(LF). The change causes a failure in verify_vendoring.sh.
Differential Revision: https://phabricator.services.mozilla.com/D192010
There was some inconsistancies in column interpretation.
Some code was assuming it was 1-based.
This patch aligns the debugger frontend with spidermonkey assumptions.
Spidermonkey and the debugger frontend both assume that:
* line is 1-based
* column is 0-based
Note that tests are still passing 1-based column as this feels more natural.
Note that CodeMirror consider both line and column to be 0-based.
Removed `toEditorRange` as that's only used by jest test.
Differential Revision: https://phabricator.services.mozilla.com/D187571
Add a new telemetry item, `WindowsFileDialogErrorCode`, which will be
included along with the failure reason for any file-dialog-specific
IPC failure crashes from the Windows file dialog utility process.
Differential Revision: https://phabricator.services.mozilla.com/D187417
Implement `ProcessingError` in `WinFileDialog{Parent,Child}` to report
errors in logging -- and, in the child process, report them via
telemetry and crash.
Differential Revision: https://phabricator.services.mozilla.com/D180344
Implement a mochitest confirming the stability of Firefox when the
file-picker crashes (patterned loosely off the existing geolocation
crash tests).
Differential Revision: https://phabricator.services.mozilla.com/D184723
An undocumented side-effect of IFileDialog::Show() is that the top-level
window which is the ancestor of the file-dialog's owner window is
disabled when the dialog is shown, and reenabled when the dialog is
dismissed.
However, if the external process containing the file-dialog crashes, the
latter action will never be taken -- we're left with an unresponsive
window. In this case, reenable it manually.
Depends on D180343
Differential Revision: https://phabricator.services.mozilla.com/D190733
When opening a new Windows file dialog, open it out-of-process if
possible. Fall back to opening it in-process if that fails. (This
behavior is configurable with a pref.)
Differential Revision: https://phabricator.services.mozilla.com/D180343
The IPC subsystem effectively owns IPC actors, and requires an explicit
call to `Close()` to destroy a toplevel actor: releasing the last RefPtr
doesn't cut it. Similarly, the UtilityProcessManager owns the utility
processes it creates, and one must explicitly call `DestroyProcess()`.
Handle both of these lifetime issues by using a custom meta-RefPtr for
WinFileDialogParent which will close the actor and kill the process upon
its final `Release()`.
Differential Revision: https://phabricator.services.mozilla.com/D180345
Create and implement a new top-level IPC protocol, `PWinFileDialog`,
using the primitives from bug 1833450 and the new sandboxing type from
the previous commit.
Again, this commit does not actually create any instances of the new
protocol; that will come in a later commit in this patchset.
Differential Revision: https://phabricator.services.mozilla.com/D180342
Create a new utility-process type for the sole use of out-of-process
instantiation of the Windows file dialog.
We do not sandbox this process type, as in certain test environments
sandboxing has been found to prevent the child process from interacting
with any other windows on the desktop -- including the parent process
window which it will need to assign as the parent of the file dialog.
Technically, no functional changes, as this commit adds no uses of this
type. (That will come later in the patchset.)
Differential Revision: https://phabricator.services.mozilla.com/D180341
Extract the creation of Windows file dialogs into a separate function,
as preparation for (sometimes) performing that remotely (that is, out-
of-process).
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D180340
