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

Parser treats comma expression as type arguments #46604

Closed
mheiber opened this issue Oct 30, 2021 · 4 comments
Closed

Parser treats comma expression as type arguments #46604

mheiber opened this issue Oct 30, 2021 · 4 comments

Comments

@mheiber
Copy link
Contributor

mheiber commented Oct 30, 2021

Bug Report

The last line below evaluates to true but is rejected by TS due to < b, c > being parsed as a type parameter list:

const a = 1;
const b = 2;
const c = 3;
const d = 4;
   (a < b, c > (d));  // Error: c refers to a value, but is being used as a type here

Adapted from rust-lang/rfcs#2527 (comment).

Sorry if this issue was known already.

🔎 Search Terms

turbofish
ambiguity
generics
"refers to a value"

🕗 Version & Regression Information

3.5.1 through 4.5.0-beta

This is the behavior in every version I tried, and I reviewed the FAQ for entries about parsing and generics.
3.33 has a slightly different error message.

Note: when using // @ts-check on a JS file the only error is that the left side of the comma expression is unused (good).

⏯ Playground Link

playground

ts-ast-viewer

💻 Code

const a = 1;
const b = 2;
const c = 3;
const d = 4;
   (a < b, c > (d)); 
//  |   |  ^ Error: e refers to a value, but is being used as a type here
//  |   ^ Error: c refers to a value, but is being used as a type here
//  ^ Error: This expression is not callable

🙁 Actual behavior

  • Errors:

    • Error: This expression is not callable
    • Error: c refers to a value, but is being used as a type here
    • e refers to a value, but is being used as a type here
  • And the AST contains CallExpression

🙂 Expected behavior

  • No errors
  • The AST contains BinaryExpression with LessThanToken etc. instead of CallExpression.
@whzx5byb
Copy link

It seems similar to #33639

@mheiber
Copy link
Contributor Author

mheiber commented Oct 30, 2021

It seems similar to #33639

Looks like a duplicate. Thanks, closing

@mheiber mheiber closed this as completed Oct 30, 2021
@MartinJohns
Copy link
Contributor

Is there any legit reason to write code like this?

@mheiber
Copy link
Contributor Author

mheiber commented Nov 1, 2021

Is there any legit reason to write code like this?

Humans no, machines maybe: #36662

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants