Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exponentiation Operator #838

Merged
merged 8 commits into from Feb 23, 2021
Merged

Conversation

tuchida
Copy link
Contributor

@tuchida tuchida commented Feb 13, 2021

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Exponentiation

#817 (comment)
Although not directly related to this feature, the test for checking the limit of the array length became very time consuming, so it has been fixed.

if (doubleLen > NativeNumber.MAX_SAFE_INTEGER) {
if (throwIfTooLarge) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that this is probably the policy.

switch (tt) {
case Token.EXP:
if (pn instanceof UnaryExpression) {
reportError("msg.no.unary.expr.on.left.exp", AstNode.operatorToString(pn.getType()));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

js> -1 ** 2
js: "<stdin>", line 2: "-" is not allowed on the left-hand side of "**".
js: -1 ** 2
js: .....^

The error appears to be in the wrong position.
I tried void reportError(String messageId, int position, int length), but it didn't change.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that the shell does this for everything -- so fixing this shouldn't be in scope for this PR assuming that errors loaded from a regular file show up on the right line.

@gbrail
Copy link
Collaborator

gbrail commented Feb 19, 2021

This change looks OK to me. I think that you've handled the various limits on the lengths properly according to the spec that you linked. I see that you have a "TODO" about an error format -- do you want to fix that first?

@tuchida
Copy link
Contributor Author

tuchida commented Feb 19, 2021

Do you mean this?

// TODO: In the case of Id_filter, CreateDataPropertyOrThrow throws a TypeError instead of ArraySpeciesCreate.
if ((id == Id_map || id == Id_filter) && length > Integer.MAX_VALUE) {

I think it's probably rare to have a problem, so I'd like to have a next time.

https://262.ecma-international.org/11.0/#sec-array.prototype.filter
In the specification, an error occurs here.

  1. Perform ? CreateDataPropertyOrThrow(A, ! ToString(to), kValue).

Not here

  1. Let A be ? ArraySpeciesCreate(O, 0).

@@ -1914,7 +1929,13 @@ private static Object iterativeMethod(Context cx, IdFunctionObject idFunctionObj
requireObjectCoercible(cx, o, idFunctionObject);
}

long length = getLengthProperty(cx, o, id == Id_map);
long length = getLengthProperty(cx, o);
// TODO: In the case of Id_filter, CreateDataPropertyOrThrow throws a TypeError instead of ArraySpeciesCreate.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what I'm asking about -- previously, we only threw an error in the case of Id_map. Is there a reason to also throw it for Id_filter too? If this is a change then you know I'm going to ask if we should check the language version too since if we didn't previously throw in this situation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

25f317e
Sorry. There should have been a slow test, but I checked and it didn't slow down without throws an error.

@gbrail
Copy link
Collaborator

gbrail commented Feb 20, 2021

Sorry I wasn't clear -- the second TODO was about exception handling, so please check out my comments.

@gbrail
Copy link
Collaborator

gbrail commented Feb 23, 2021

Thanks for pulling this together!

@gbrail gbrail merged commit 00ff021 into mozilla:master Feb 23, 2021
@tuchida tuchida deleted the exponentiation-operator branch May 27, 2021 08:14
@p-bakker p-bakker added this to the Release 1.7.14 milestone Oct 13, 2021
@p-bakker p-bakker added the feature Issues considered a new feature label Oct 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Issues considered a new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants