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

Most implementations seem to have missed that await x ** 2 is not legal #2197

Open
bakkot opened this issue Oct 3, 2020 · 10 comments
Open
Labels
needs editorial changes needs test262 tests The proposal should specify how to test an implementation. Ideally via github.com/tc39/test262

Comments

@bakkot
Copy link
Contributor

bakkot commented Oct 3, 2020

Moving discussion from microsoft/TypeScript#40916.

Quoting @DanielRosenwasser:

I can't seem to find a derivation for ExponentiationExpression to await 1 ** 1.
ExponentiationExpression seems to need an UpdateExpression on the left, which does not include an AwaitExpression. On the other hand, UnaryExpression does, but that's kind of the point of the syntax split.

My reading (now that I look) matches his. But V8, SpiderMonkey, JavaScriptCore, engine262, babel, shift, flow, and acorn all seem to have missed this. (But not TypeScript or XS!) We should probably call it out with a big note in the spec, or, since it might now be web reality, possibly change the spec to match implementations.

@bakkot
Copy link
Contributor Author

bakkot commented Oct 3, 2020

Incidentally I'd be happy with making this legal, since await a + 2 definitely is.

@DanielRosenwasser
Copy link
Member

My vote is more to keep things as is and fix implementations if possible, as it's more inconsistent otherwise.

@jridgewell
Copy link
Member

As an extra step, this proves that each browser is parsing it as (await X) ** 2 and not await (X ** 2):

(async function f() {
  const obj = {
    valueOf() {
      console.log('Parsed as `await (X ** 2)`');
      return 1;
    },
    then(f) {
      console.log('Parsed as `(await X) ** 2`');
      f(2);
    },
  };
  const value = await obj ** 2;
  return value;
})()

@Jack-Works
Copy link
Member

Does it the same order for "await x + y" (await x) + y not await (x + y)?

@bakkot
Copy link
Contributor Author

bakkot commented Oct 4, 2020

Does it the same order for "await x + y" (await x) + y not await (x + y)?

Yes, await x + y is equivalent to (await x) + y.

@bakkot
Copy link
Contributor Author

bakkot commented Oct 5, 2020

Another fun case:

(async () => {
  await -x ** 2;
})();

The tools which forbid await x ** 2 also forbid the above, but of those which allow that case, only V8 forbids this one.

@littledan
Copy link
Member

Are there test262 tests for this case?

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jan 19, 2021
…and side of an exponentiation expression. r=yulia

We simply missed to classify `await` expressions as unary expressions.

Spec issue: tc39/ecma262#2197

Depends on D101014

Differential Revision: https://phabricator.services.mozilla.com/D101015
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Jan 25, 2021
…and side of an exponentiation expression. r=yulia

We simply missed to classify `await` expressions as unary expressions.

Spec issue: tc39/ecma262#2197

Depends on D101014

Differential Revision: https://phabricator.services.mozilla.com/D101015

UltraBlame original commit: 63f1d59a1cef6405af9caf9f0d20b60eb40c137c
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Jan 29, 2021
…and side of an exponentiation expression. r=yulia

We simply missed to classify `await` expressions as unary expressions.

Spec issue: tc39/ecma262#2197

Depends on D101014

Differential Revision: https://phabricator.services.mozilla.com/D101015
@bakkot bakkot added needs test262 tests The proposal should specify how to test an implementation. Ideally via github.com/tc39/test262 needs editorial changes labels Feb 17, 2021
@bakkot
Copy link
Contributor Author

bakkot commented Feb 17, 2021

Consensus from discussion in plenary was that we should leave it as-is but add a test262 for it. Speaking as editor, I also think it warrants a note in the spec itself.

@DanielRosenwasser
Copy link
Member

Just to clarify, you mean leave the spec text as-is, right?

@bakkot
Copy link
Contributor Author

bakkot commented Feb 18, 2021

The normative text, yes. I think it warrants an editorial note.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs editorial changes needs test262 tests The proposal should specify how to test an implementation. Ideally via github.com/tc39/test262
Projects
None yet
Development

No branches or pull requests

6 participants
@jridgewell @littledan @DanielRosenwasser @bakkot @Jack-Works and others