Also: Change signature of these functions and methods to all have the same arguments in the same order: (cx, obj, id, v, receiver). Also change v from MutableHandleValue to HandleValue.
There is no change in behavior.
In fact the new error message `JSMSG_SET_NON_OBJECT_RECEIVER` is
impossible to trigger from scripts for now, I think (after re-reading
the whole patch with this in mind). JS_ForwardSetPropertyTo is the only
way to get a non-object receiver into the engine, but no caller
currently does so.
We're installing new pipes here, and they should work, but for now it's
the same cold water flowing through as before. Actually hooking up the
hot water is left for another bug (one with tests, not to put too fine a
point on it).
Notes:
* InvokeGetterOrSetter had to be split into two functions:
InvokeGetter takes a MutableHandleValue out-param,
InvokeSetter a HandleValue in-param.
* Watchpoints can still tamper with values being assigned. So can
JSSetterOps. I'm pleased we can support this craziness in a way that
doesn't have to spread via the type system to encompass the entire
codebase.
* Change in GlobalObject::setIntrinsicValue is not really a change.
Yes, it asserted before, but an exception thrown during self-hosting
initialization is not going to go unnoticed either.
* Since the receiver argument to js::SetProperty() is at the end now, it
makes sense for it to be optional. Some callers look nicer.
Add a `tags` attribute to a test or DEFAULT section in a manifest:
[test_foo]
tags = foo
Then run all tests with a given tag by passing in `--tag foo` to a supported test harness. So far mochitest, xpcshell and marionette are supported.
========
https://hg.mozilla.org/integration/gaia-central/rev/561bf3f92ea1
Author: autolander <bug.autolander@gmail.com>
Desc: Bug 1102835 - merge pull request #28648 from mnjul:bug_1102835_kb_app_use_ud_to_predict to mozilla-b2g:master
========
https://hg.mozilla.org/integration/gaia-central/rev/a1670e6c818d
Author: John Lu [:mnjul] <jlu@mozilla.com>
Desc: Bug 1102835 - Part 3: Enable user dictionary in keyboard settings by default
========
https://hg.mozilla.org/integration/gaia-central/rev/0d8a2cf956ad
Author: John Lu [:mnjul] <jlu@mozilla.com>
Desc: Bug 1102835 - Part 2: Adjust merging strategy and uniform frequency
- The uniform frequency has been reduced from 31 (max) to 10 to facilitate merging strategy's threshold for user dictionary.
- In latin.js's prediction merging strategy, if we want to prioritize user dictionary predictions, we can only do so if such predictions have weight >= 1.
========
https://hg.mozilla.org/integration/gaia-central/rev/51246f791867
Author: John Lu [:mnjul] <jlu@mozilla.com>
Desc: Bug 1102835 - Part 1: Keyboard UserDictionary: Formally enable prediction engine to predict from user dictionary
- We use only one worker which instantiates two Predictions object and use Promise.all() to receive the asynchronous results and merge the results.
- A setUserDictionary() function has been added to worker since user dictionary may change even when layout language isn't changed. Necessary wiring from latin.js is added.
- An empty user dictionary is stored as |undefined| in IndexedDB, and worker uses a strategy- & proxy-derived pattern to decide whether user dictionary prediction is invoked.
- Predictions() are no longer IIFE since we need more than one instances now.
- Worker.js is now handled by jshint, removed from jshint xfail list.
- The suggestions passed from worker to latin.js annotate whether a suggestion is from user dictionary; latin.js will always consider to show at least one suggestion from user dictionary.
Conflicts:
apps/keyboard/js/imes/latin/predictions.js
apps/keyboard/test/unit/imes/latin/worker_test.js
