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

Fix #4533: chained calls incorrectly wrapping enclosing implicit objects #4534

Merged
merged 1 commit into from
May 12, 2017

Conversation

xixixao
Copy link
Contributor

@xixixao xixixao commented May 1, 2017

Fixes #4533.

I looked through the other open and closed method chaining issues and this doesn't seem to fix any of them. It's possible it fixes some other issues I'm not aware of (I kinda feel like it should change some behavior, but we don't have any existing tests covering it).

@GeoffreyBooth GeoffreyBooth requested a review from lydell May 1, 2017 17:27
@GeoffreyBooth
Copy link
Collaborator

LGTM. Do you think it’s enough of a breaking-change risk that we should make this only on 2? (I’m thinking probably not, but just wanted to make sure.)

@xixixao
Copy link
Contributor Author

xixixao commented May 1, 2017

I think this should be fixed in 1 (alas it is a breaking change, so it should go into the "next" version in our brave no-semver world).

a: id 1
b: id {a: 42}
.a
eq 42, result.b
Copy link
Collaborator

Choose a reason for hiding this comment

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

This test would pass if it was parsed as id({ a: 42 }.a) or id({ a: 42 }).a.

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, let me fix that.

@GeoffreyBooth
Copy link
Collaborator

Can you please explain how this would be a breaking change?

@xixixao
Copy link
Contributor Author

xixixao commented May 7, 2017

This is a breaking change in the sense that code which previously compiled now compiles to something else. Luckily the previous compilation was not really meaningful, so no one should have hopefully relied on it. Changes like these are rather common here.

@GeoffreyBooth
Copy link
Collaborator

FYI @xixixao I reviewed all the open issues. I put “Chaining:” in the titles for ones involving chaining or leading dots: https://github.com/jashkenas/coffeescript/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20Chaining

Do you mind reviewing those after you’re done with this? I bet most of them are related. I also put “Lexer:” in the title for anything that seemed like it had to do with the code in lexer.coffee, which you seem to be quite expert on.

@xixixao
Copy link
Contributor Author

xixixao commented May 7, 2017

I've already done that, I'll put the summary here later. I'm definitely no expert in any part of the compiler.

@xixixao xixixao force-pushed the chains-in-object-literals branch from 74bf845 to 253e9d4 Compare May 7, 2017 17:48
@xixixao xixixao force-pushed the chains-in-object-literals branch from 253e9d4 to 4b5e777 Compare May 7, 2017 17:51
@xixixao
Copy link
Contributor Author

xixixao commented May 7, 2017

Rebased and fixed tests.

@GeoffreyBooth
Copy link
Collaborator

@lydell what do you think?

Copy link
Collaborator

@lydell lydell left a comment

Choose a reason for hiding this comment

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

I have always had trouble understanding the rewriter. This is a nice-looking little patch. @xixixao probably knows best how chaining works in CoffeeScript. I can't really tell what this patch does, but if the tests pass and this fixes a bug, then I'd say go for it.

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.

Lexer: Chaining: Method chaining wraps enclosing object incorrectly
4 participants