Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Conversation

@rhendric
Copy link
Collaborator

@rhendric rhendric commented Feb 5, 2016

Certain expressions—integers (with or without a preceding +/-), null,
and void—when used as sources of for loops resulted in illegal
JavaScript being generated. While (42).length is a silly but legal thing
to do, 42.length is an actual SyntaxError in JS. This commit adds checks
to wrap potentially problematic expressions in parentheses.

src/ast.ls Outdated
then "#idx #{ '<>'char-at pvar < 0 }#eq #tvar"
else "#pvar < 0 ? #idx >#eq #tvar : #idx <#eq #tvar"
else
if @source instanceof Literal and @source.value is /^[0-9]+$/
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems a bit too specific

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I thought so at first too, but all of the following are handled gracefully by JavaScript:

  • 1e8
  • 0.0
  • true/false/null

This is the most general case I could find that triggers the syntax error. (Ah crap, I just found one more: negatives. I'll throw a -? in there.)

Copy link
Contributor

Choose a reason for hiding this comment

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

(JS doesn't even have negative literals)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

And yet -42.length triggers a syntax error anyway.

I'm starting to have misgivings about this approach; maybe I should be adding robustness (generating (42).length) instead of trying to catch the problem cases and raise errors? I was reluctant to do that at first because errors seem better than compiling things that I know are wrong, but this is turning into a slightly awkward patch. Do you have an opinion?

Copy link
Contributor

Choose a reason for hiding this comment

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

Not really, but I never had this kind of error

Certain expressions--integers (with or without a preceding +/-), null,
and void--when used as sources of for loops resulted in illegal
JavaScript being generated. While (42).length is a silly but legal thing
to do, 42.length is an actual SyntaxError in JS. This commit adds checks
to wrap potentially problematic expressions in parentheses.
@rhendric rhendric changed the title catch integer literal loop sources add robustness to generated loop code Feb 7, 2016
@rhendric
Copy link
Collaborator Author

rhendric commented Feb 7, 2016

(For why-the-heck-does-he-want-this background: I was working on #162 and kept getting very annoying-to-diagnose errors from the test suite. I had to binary search the files with comments, because of course the JavaScript SyntaxErrors didn't give me a line number. Not fun. I'm just trying to help out the next guy who goes experimenting with loop, slice, or spread syntax.)

gkz added a commit that referenced this pull request Feb 8, 2016
add robustness to generated loop code
@gkz gkz merged commit fbc1502 into gkz:master Feb 8, 2016
@rhendric rhendric deleted the for-literal-error branch May 4, 2023 20:17
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

Successfully merging this pull request may close these issues.

3 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.