This class doesn't have anything to do with __exposedProps__ any more,
so give it a more descriptive name. We'd still like to remove it
entirely eventually.
MozReview-Commit-ID: 87KCpG6f8rI
--HG--
extra : rebase_source : 98a51a6af0fc8446dbcd8efa083d6c79286279d3
This patch gently removes support for __exposedProps__ by changing
ExposedPropertiesOnly::check() to always return false, while still
failing silently in deny for some kinds of access.
The tests that I changed all involve testing the behavior with
__exposedProps__. I adjusted them to expect it to fail, or to adjust
the error message they get when they fail. That seemed better than
deleting them entirely.
Note that test_bug1065185.html had a bug, so that it never executed
the first case. I fixed that, and then fixed up the test to work when
__exposedProps__ is not supported.
This also removes various bits of the test framework that use
__exposedProps__, but don't actually need to.
MozReview-Commit-ID: 8fvkAmITmXY
--HG--
extra : rebase_source : ef7e2c55adc12511f17f3865ebb46c343875f0b3
The entire purpose of this patch is to support accessing this bit from
WrapperFactory (see the last hunk) without going through a particular
scope.
--HG--
extra : rebase_source : d2952e981f4b277e6ca565077c6e6d18c69c8df5
These flags don't guarantee that the getter and setter functions are defined.
MozReview-Commit-ID: GBcoRYoKHqL
--HG--
extra : rebase_source : 1234ec91cf05566a3130360b152bf2cb986ec1c3
Because it's just a wrapper for js_free().
Furthermore, JS_smprintf() and friends return a JS::UniqueChars, which is also
wired up to free with js_free(). So having the indirection via
JS_smprintf_free() obfuscates things.
--HG--
extra : rebase_source : 1db80199dc801a2684fffe2a5fd5349a42c6941b
Removing the redundant unwrapping improves ~15% for the micro benchmark (bug
1348095 comment 3) on my desktop. Replace the parameter jsWrapper of
resolveOwnProperty() because it is not used.
MozReview-Commit-ID: ULHX8vyMrZ
--HG--
extra : rebase_source : b76e688f53722cfd24466668b68043366f25e917
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
In most cases no expando object has ever been attached, we don't need to do a
lot of things and realize it in the last minute.
MozReview-Commit-ID: 5u9ivZQj5L8
--HG--
extra : rebase_source : 71405f978a7c832a6694206bf0410debe596967c
The patch makes the following proxy changes:
* The number of slots in ProxyValueArray is now dynamic and depends on the number of reserved slots we get from the Class.
* "Extra slots" was renamed to "Reserved slots" to make this clearer.
* All proxy Classes now have 2 reserved slots, but it should be easy to change that for proxy Classes that need more than 2 slots.
* Proxies now store a pointer to these slots and this means GetReservedSlot and SetReservedSlot can be used on proxies as well. We no longer need GetReservedOrProxyPrivateSlot and SetReservedOrProxyPrivateSlot.
And some changes to make DOM Proxies work with this:
* We now store the C++ object in the first reserved slot (DOM_OBJECT_SLOT) instead of in the proxy's private slot. This is pretty nice because it matches what we do for non-proxy DOM objects.
* We now store the expando in the proxy's private slot so I removed GetDOMProxyExpandoSlot and changed the IC code to get the expando from the private slot instead.
Most of the time, the return value of this method should be checked,
because behavior should depend on whether or not an exception is
thrown. However, if it is called immediately after a throw it doesn't
need to be checked because it will always return true. bz said there
is no public API that lets you assume there is an exception because it
would be "too easy to misuse".
MozReview-Commit-ID: CqyicBbcNjW
--HG--
extra : rebase_source : a5b74ba88a927a90d491ceb8f0b750a67f62b0f4
