That was redundant with the manifest being added with MT (although useful
for mingw builds, that don't use MT), but is also now handled by the
automatic creation of rc files.
Differential Revision: https://phabricator.services.mozilla.com/D86156
We are currently relying on two different ways to insert side-by-side
manifests in binaries on Windows: through resource files, or through
the use of MT. The latter is not supported on mingw builds, which is
not great.
Link.exe has options to add a manifest at link time without relying on
either method above, but that's not supported on mingw either.
So the best we can do is to move everything to using resource files.
This also avoids using MT, which, on cross builds, requires using wine.
Ideally, the manifests would be declared in moz.build, but that
complicates things for cases like TestDllInterceptor, where there are
multiple binaries in the same directory, but only one of them needs the
manifest. This keeps the status quo of getting the manifest
automatically from the source directory.
Differential Revision: https://phabricator.services.mozilla.com/D85382
We're currently not using the feature, and host programs ought only
to be used during the build, so I don't expect the feature to ever
be necessary.
Differential Revision: https://phabricator.services.mozilla.com/D86167
The resource file is always generated so being able to configure its name
is not useful. On the other hand, the way things are currently implemented,
the lack of RESFILE also makes RCFILE ignored, which we fix at the same
time.
And remove a spurious RESFILE in widget/windows/moz.build, where no binary
is produced, which means RESFILE had no meaning.
Differential Revision: https://phabricator.services.mozilla.com/D86154
Because while the original perl script was added to add version info
to Windows binaries, it does more and will do even more with upcoming
changes.
Differential Revision: https://phabricator.services.mozilla.com/D86153
RCFILE is only actually used when the moz.build that contains it defines
a binary, which is not the case for dav1d, which ends up in gkmedias.dll.
Which also means that moving the definition to gkmedias would also not
make sense, since all dav1d.rc does is add descriptors to the dll that it
contains dav1d and what version, but gkmedias.dll contains other things
too.
Differential Revision: https://phabricator.services.mozilla.com/D86152
It was only ever set to the same value as its default, except in
comm-central, where it is unset, but in directories that now don't link
anything (they did back when binary components were a thing).
Differential Revision: https://phabricator.services.mozilla.com/D85381
clang-11 has a new warning that fires when you pass a 256-bit vector type as a parameter or return value, and your compilation doesn't enable AVX. The aim is to warn you that the ABI is different depending on whether you enable AVX, which could become a problem if AVX and non-AVX files communicate through such parameters.
While the intent is good, it's not really worth 1800 lines of log spam for us. We have only a tiny number of AVX compilations in media codecs, and the only things they interchange with other code are buffer pointers.
Differential Revision: https://phabricator.services.mozilla.com/D86107
The CSS Compatibility Tooltip tests cover the following cases:
* Check if the contents of the tooltip match the rendered template
* Check compatible rules aren't falsely marked incompatible
* Check incompatible rules are marked correct with icon appearing next to it
* Check toggling rule disable hides the icon
* Check adding rules updates the compatibilility status
* Check the compatibility icon disappears if a fix is added
Differential Revision: https://phabricator.services.mozilla.com/D84218
Use CompatibilityActor to fetch the compatiblity information for
a particular CSS declaration and show a tooltip for the
incompatible CSS declaration that may cause issue on platform
Differential Revision: https://phabricator.services.mozilla.com/D81474
This patch adds
`devtools.inspector.ruleview.inline-compatibility-warning.enabled`
that covers the development of the inline CSS compatiblity warning
tooltip
Differential Revision: https://phabricator.services.mozilla.com/D81473
Previously CompatibilityActor could only compute the compatiblity
issues taking node actor. However with the implementation of
inline compatibility warning, it becomes necessary to compute
compatiblity issue from the CSS declaration block. This patch
exposes a getCssDeclarationBlockIssues and add browser dataset
fetch within the actor for inline warnings.
Differential Revision: https://phabricator.services.mozilla.com/D81472
Prior to this patch, if we aborted with AbortReason::Disable (for example, because it contains an unsupported opcode), then we would abort the entire compilation. With this patch, we mark the script uninlineable, clean up, and continue as if we had not done trial inlining. This improves Octane by ~1.3%.
The CacheIR for the callsite still contains a CallInlinedFunction. The best approach I could come up with was to transpile CallInlinedFunction differently depending on whether we were actually inlining. If not, it is treated like a regular CallScriptedFunction.
An alternative approach would be to check all the conditions that could cause AbortReason::Disable beforehand (possibly in BytecodeAnalysis) and preemptively mark the script unlineable, with the downside of creating another piece of code that had to be kept in sync with WarpOracle, and there are just enough quirky cases to make that seem like a bad idea. In the future, we could combine the approaches by preemptively marking the easy cases and relying on this code for the rest.
Depends on D86102
Differential Revision: https://phabricator.services.mozilla.com/D86103
With these conservative heuristics, trial inlining gives a performance improvement on Octane and does not regress Speedometer.
Depends on D86101
Differential Revision: https://phabricator.services.mozilla.com/D86102
This changes the duplicate checking/caching implemented by |parsed| to be
based on the name of the protocol etc. we're loading, not the file name.
This lets us detect when a protocol is being defined in two different
files.
This can happen if one file is included earlier in the resolve path than
a file explicitly specified on the command line. Any includes will resolve
to the former, and then we'll attempt to parse the latter. Before this
patch, this would result in weird errors, because there would be multiple
protocol types with the same name.
Differential Revision: https://phabricator.services.mozilla.com/D86113
The functionality has been fully subsumed by the new
initialBrowsingContextGroupId attribute, so it is no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D85653
This attribute can be used to force non-tab extension browsers to be loaded in
the correct BrowsingContextGroup, and also subsumes the existing
sameProcessAsFrameLoader uses in extension code.
Differential Revision: https://phabricator.services.mozilla.com/D85652
This attribute, when combined with the remoteType attribute, should subsume all
callers of sameProcessAsFrameLoader, and also support selecting the same process
as an out-of-process iframe.
Differential Revision: https://phabricator.services.mozilla.com/D85651
This attribute will subsume the existing sameProcessAsFrameLoader attribute. It
works by specifying the BrowsingContextGroup which the initial BrowsingContext
in a <browser> should be created within.
Due to bug 1652144, all documents within the same BrowsingContextGroup with the
same remote type will be loaded in the same process, meaning that specifying
both "initialBrowsingContextGroupId" and "remoteType" will cause the initial
about:blank document to be loaded in a specific content process.
Differential Revision: https://phabricator.services.mozilla.com/D85650
This seems like a nice assertion to have so arrange that the weakref target is not set if registration fails. Also I fixed places where we didn't report out of memory on failure.
Depends on D86185
Differential Revision: https://phabricator.services.mozilla.com/D86186
Mike Hommey
David Major
Matt Woodrow
Mihai Alexandru Michis
Kriyszig
Julian Descottes
Andrew Halberstadt
Jeff Gilbert
Jamie Nicol
shravanrn@gmail.com
Martin Stransky
Chris H-C
Iain Ireland
Kris Maglione
Dave Townsend
Brindusan Cristian
Andrew McCreight
Andrew Osmond
Erik Nordin
Nika Layzell
Ting-Yu Lin
Jon Coppeard