`sorted(aliasedMembers)` looks like it is sorting by `__repr__`, which
contains the address of the object, like `<WebIDL.IDLMethod object at
0x7f83be5d8b50>`.
Differential Revision: https://phabricator.services.mozilla.com/D52821
--HG--
extra : moz-landing-system : lando
Dictionaries that we never initialize with JS values don't need a full-featured
Init() method. Instead, we output a cut-down Init() method that doesn't even
take a JSContext and Value as argument, and skips as much work as it can. It
uses constant-false for "is the value present?", but also, to avoid compilation
errors due to use of `cx` and `val` in now-dead conversion code, it tells the
native-to-JS conversion machinery that the value is always missing, which lets
it skip most of the the work it would normally try to do and just output
initialization to the default value. We only need to do this for members that
have default values; the others either remain no-passed or are required members
with no default-initialization behavior.
This saves about 330KB of codesize on Linux64 without PGO and 285KB with PGO.
Differential Revision: https://phabricator.services.mozilla.com/D48007
--HG--
extra : moz-landing-system : lando
This saves about 270KB of codesize on Linux64 without LTO, or 20KB with LTO.
The basic idea is that we can flag dictionaries that need to-JS conversion
(hence ToObjectInternal) based on various IDL uses (return value in normal
interface, argument in callback, etc) and then annotate the ones that are
converted to JS manually in C++ code.
The mozwebidlcodegen changes are needed because non-local changes (e.g. whether
a dictionary is used as a return value somewhere) can now affect the code
generation for a dictionary and hence whether the relevant binding file should
be regenerated. Since these changes can happen in any .webidl file, we need to
check for them. We can't track this via the dependency set on the dictionary
itself, because that would not notice new uses being added.
Differential Revision: https://phabricator.services.mozilla.com/D48006
--HG--
extra : moz-landing-system : lando
I don't know when we stopped raising them, but we did at some point.
I am leaving the capability to not generate a union's ToJSVal method, because I will need it soon.
Differential Revision: https://phabricator.services.mozilla.com/D48554
--HG--
extra : moz-landing-system : lando
This saves about 200KB of codesize on Linux64 without LTO. No effect with LTO,
but is needed for the following patches to work.
Very few dictionaries need these conversions, so explicit opt-in is fine.
Differential Revision: https://phabricator.services.mozilla.com/D48005
--HG--
extra : moz-landing-system : lando
Returning a span ensures that consumers don't try to use this without a length,
but does hide the fact that our string is always null-terminated, at least for
the moment...
Differential Revision: https://phabricator.services.mozilla.com/D49531
--HG--
extra : moz-landing-system : lando
We want to remove flat strings (JSFlatString). With this patch we only expose
linear strings (JSLinearString) to API consumers.
This is very mechanical for the most part, because code typically only cares
about linear strings and not the null-termination aspect.
CTypes's Library.cpp has some Windows-specific code where we relied on null-terminated
strings. This patch adds JS_CopyStringCharsZ for that use case.
Differential Revision: https://phabricator.services.mozilla.com/D48314
--HG--
extra : moz-landing-system : lando
The new error message is still not great, but it's a lot better than having %s
as the description of what's going on.
Differential Revision: https://phabricator.services.mozilla.com/D47915
--HG--
extra : moz-landing-system : lando
Since unions can now end up a in binding header, it's only a problem when the
two dictionaries are in one header and the union is in a different one. If all
three are in the same header, for example, there is no issue.
Differential Revision: https://phabricator.services.mozilla.com/D47195
--HG--
extra : moz-landing-system : lando
Since unions can now end up a in binding header, it's only a problem when the
two dictionaries are in one header and the union is in a different one. If all
three are in the same header, for example, there is no issue.
Differential Revision: https://phabricator.services.mozilla.com/D47195
--HG--
extra : moz-landing-system : lando
There are no callers who want this. They all filter out external interfaces in various ways; we might as well do it up front.
Differential Revision: https://phabricator.services.mozilla.com/D46695
--HG--
extra : moz-landing-system : lando
A bunch of loop-detection, etc, complexity goes away because mixins are not
interfaces and the mixin syntax does not allow various things we had to guard
against in terms of maplikes and whatnot.
Differential Revision: https://phabricator.services.mozilla.com/D46524
--HG--
extra : moz-landing-system : lando
It doesn't really make sense to enforce this behavior for calls on stack
variables (which presumably we then want to do something with) and doesn't
necessarily make sense to enforce it for member variables either.
Differential Revision: https://phabricator.services.mozilla.com/D46105
--HG--
extra : moz-landing-system : lando
This is so that SetUseCounter is as cheap as possible.
This is in preparation for hooking the CSS use counters to telemetry. We want
CSS use counters to be fast and be propagated at once to the parent page. This
will make sure to use the same setup as everywhere else.
Differential Revision: https://phabricator.services.mozilla.com/D44645
--HG--
extra : moz-landing-system : lando
Otherwise we're computing (1ull << CHAR_BIT) * sizeof(...), which is not
quite what we wanted.
Differential Revision: https://phabricator.services.mozilla.com/D41773
--HG--
extra : moz-landing-system : lando
Merge js::FreeOp and JSFreeOp, but alias the former to the latter while we fix uses.
Differential Revision: https://phabricator.services.mozilla.com/D41410
--HG--
extra : moz-landing-system : lando
Merge js::FreeOp and JSFreeOp, but alias the former to the latter while we fix uses.
Differential Revision: https://phabricator.services.mozilla.com/D41410
--HG--
extra : moz-landing-system : lando
We could get rid of the need to specify the impl class at the callsite by
taking a T** instead of returning an already_AddRefed<T>, but I'm not sure
which is uglier...
The change from `globalHolder->GetGlobalJSObject()` to `global.Get()` is OK,
because `globalHolder` was coming from the nsISupports attached to
`global.Get()` anyway, so those are the same global JS object.
Differential Revision: https://phabricator.services.mozilla.com/D40060
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
`= {}` can now be used to indicate that an optional dictionary should have the
default value of 'default-initialized dictionary'
Differential Revision: https://phabricator.services.mozilla.com/D36504
--HG--
extra : moz-landing-system : lando
Add [LegacyWindowAlias] extended attribute support for WebKitCSSMatrix and webkitURL.
Differential Revision: https://phabricator.services.mozilla.com/D35601
--HG--
extra : moz-landing-system : lando
