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

Pass through octal and binary literals as-is #4318

Merged
merged 1 commit into from
Sep 27, 2016

Conversation

JimPanic
Copy link
Contributor

See coffeescript6/discuss#45

Note: I'm deliberately creating this PR towards branch 2 because it is not opt-in and I'm not sure how many current JS environments implement the binary and octal literals as ES2015 does.


numberValue = number

unless /^(0o[0-7]+)/.test(number) and /^(0b[01]+)/.test(number)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Isn’t this a constant condition (unless false)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch, thanks.

toJS = (str) ->
CoffeeScript.compile str, bare: yes
.replace /^\s+|\s+$/g, '' # Trim leading/trailing whitespace

Copy link
Collaborator

Choose a reason for hiding this comment

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

Following the style of all other tests (except import/export), all these added tests should be removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, I didn't know that. So no compilation tests at all?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah, that’s been the rule. Only check that the CoffeeScript does what is expected.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, cool. 👍 I like removing things.

@JimPanic JimPanic force-pushed the octal-and-binaries-as-is branch 2 times, most recently from 499bc0d to a940a77 Compare September 26, 2016 11:29
@JimPanic
Copy link
Contributor Author

Removed the tests and fixed the logic.

@lydell
Copy link
Collaborator

lydell commented Sep 26, 2016

@JimPanic While reviewing this PR, I found a bug in master. I fixed that bug, and have also updated the 2 branch with the fix. Could you please rebase this PR?

@JimPanic
Copy link
Contributor Author

Just to be clear: is there a reason to parse hex, oct and binary in 2?

@JimPanic
Copy link
Contributor Author

Oh, of course they need to be parsed - for the Infinity check.

@lydell
Copy link
Collaborator

lydell commented Sep 26, 2016

Yep. Btw, you seem to have completely messed up the commits now :) git is so much fun

@JimPanic
Copy link
Contributor Author

Yes, totally. And your fix confused me. :) Basically you refactored it so well, I just have to remove two lines again. So this will be a new force push to my branch; on top of your last commit on 2.

@JimPanic JimPanic force-pushed the octal-and-binaries-as-is branch from 9cfca02 to 329b2d1 Compare September 26, 2016 16:04
@lydell
Copy link
Collaborator

lydell commented Sep 26, 2016

Nice! LGTM. @GeoffreyBooth what about you?

@GeoffreyBooth
Copy link
Collaborator

Is this really just +1 −2 changes? It doesn’t get much simpler than that. Looks good to me assuming we don’t need any tests (?)

@lydell
Copy link
Collaborator

lydell commented Sep 26, 2016

I've missed compiled output tests from time to time. For example, when reviewing this PR, I found an output bug that still gave the same runtime result. It would be nice to write tests for such things. I've just never thought about it before, since I just accepted the style that was already used. Perhaps it's time for a change.

@JimPanic
Copy link
Contributor Author

Hence why I added the tests in the first place, but I didn't know there was this rule.

We could have compilation tests in a seperate folder/repository maybe?

@lydell
Copy link
Collaborator

lydell commented Sep 27, 2016

Compilation tests shouldn't be a blocker for this PR, though? That's a separate issue?

@JimPanic
Copy link
Contributor Author

Yeah, that's definitely something for a different issue.

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

Successfully merging this pull request may close these issues.

4 participants