Closed
Bug 482028
Opened 16 years ago
Closed 6 years ago
narcissus fails js tests due to lack of support for version() or options()
Categories
(Other Applications Graveyard :: Narcissus, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: bc, Unassigned)
References
Details
Attachments
(1 file)
1.36 KB,
patch
|
mrbkap
:
review-
|
Details | Diff | Splinter Review |
version() and options() support is required to run the js tests. narcissus does not define them however.
Flags: in-testsuite+
Comment 1•16 years ago
|
||
We could mock them up, but since Narcissus doesn't support all of the options (e.g. E4X) that SpiderMonkey does, I have a feeling that adding these will simply move where the tests fail.
Comment 2•16 years ago
|
||
Yeah, mock-up. We don't aim to run more than the ecma_* tests on Narcissus.
/be
Reporter | ||
Comment 3•16 years ago
|
||
Ok. I can mock them up in js/tests/shell.js if that is ok.
Comment 4•16 years ago
|
||
Why not just mock them up in js.js?
Comment 5•16 years ago
|
||
Er, I meant jsexec.js.
Reporter | ||
Comment 6•16 years ago
|
||
bc looks up from js/tests and realizes that there is an entire world out there...
Comment 7•16 years ago
|
||
Reporter | ||
Updated•16 years ago
|
Attachment #374778 -
Flags: review?(mrbkap)
Comment 8•16 years ago
|
||
Comment on attachment 374778 [details] [diff] [review]
patch to add options to primitives, and to remove "version: null"
>diff -r ea128fc02710 js/narcissus/jsexec.js
>+ // version: null -- CF - had problems with shell.js in js/tests
>+ options: options
Won't this lie? In particular, if you run a narcissus shell with the JIT on in SpiderMonkey, I think you'll get spurious errors. I'm not sure what the testsuite expects, but I was sort of expecting a no-op function since Narcissus doesn't support any of SpiderMonkey's options.
If you change that, can you add a version function that always returns 150? Or do things still break?
> case RETURN:
>+ /* CF: Was
> x.result = getValue(execute(n.value, x));
>+ */
>+ x.result = n.value.type==undefined ?
>+ undefined :
>+ getValue(execute(n.value, x));
Since this is all in version control, we don't need to record in the source what the changes you make are. However, it would be good to add a comment about why you're doing this. I suppose this is the only place in the interpreter where it's possible to enter with an undefined (really non-existant) value?
Also, please follow existing conventions in the file, I think this should be formatted as:
x.result = (n.value.type == undefined) ? undefined
: getValue(execute(n.value, x));
Attachment #374778 -
Flags: review?(mrbkap) → review-
Updated•15 years ago
|
Assignee: general → nobody
Component: JavaScript Engine → Narcissus
Flags: in-testsuite+
Product: Core → Other Applications
QA Contact: general → narcissus
Comment 9•6 years ago
|
||
Closing as Narcissus isn't maintained anymore.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Updated•6 years ago
|
Product: Other Applications → Other Applications Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•