-
Notifications
You must be signed in to change notification settings - Fork 11
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
Double colon stubbed function name + double colon assignment = cryptic parsing bug #23
Comments
Thanks for finding this bug and writing it up. It turns out to happen whenever something is assigned to a function call. I haven't quite figured out why, except that something about how we're mangling names allows the original function to be called, but not called then assigned to. To be honest I've never been a fan of assigning to function calls. I don't have the bandwidth to figure out why this is broken and fix it. If you do, please feel free. Otherwise, I certainly agree that at least the error should be clearer in specifying that double colon stubbed functions cannot be assigned to. If you are able to create a pull request to that effect, it would be appreciated. |
Thanks for getting back. I wish I had time to work on a pull request, but I don't in the near future :( Meanwhile I'm working around this by just importing the function into my package namespace so I don't have to use the double colon. |
The parsing was failing because `foo::bar<-` is not parse-able, however foo::`bar<-` Is parse-able, so that is what we do now. A related issue was the mangling was creating names like `fooXXXbar<-`, which again is not parse-able, so that was changed to quote the whole name with backticks. Fixes #23
The parsing was failing because `foo::bar<-` is not parse-able, however foo::`bar<-` Is parse-able, so that is what we do now. A related issue was the mangling was creating names like `fooXXXbar<-`, which again is not parse-able, so that was changed to quote the whole name with backticks. Fixes #23
The parsing was failing because `foo::bar<-` is not parse-able, however foo::`bar<-` Is parse-able, so that is what we do now. A related issue was the mangling was creating names like `fooXXXbar<-`, which again is not parse-able, so that was changed to quote the whole name with backticks. Fixes #23
The parsing was failing because `foo::bar<-` is not parse-able, however foo::`bar<-` Is parse-able, so that is what we do now. A related issue was the mangling was creating names like `fooXXXbar<-`, which again is not parse-able, so that was changed to quote the whole name with backticks. Fixes #23
I wish I could have crafted a more comprehensible title, but this is a weird bug. Here's a reproducible example:
The indicated line produces the following error:
I found this bug in testing my own package, where another
<package>::function<-
statement (notbase::names<-
) gave me the same "unexpected end of input" error. It took me a while to even figure out it was mockery that was causing the problem, since it doesn't appear anywhere in the stacktrace.The text was updated successfully, but these errors were encountered: