Implement more assignment operators
This generates code for all of the assignment operators available for assignment statements. This includes shortcuts such as "+=" or "%=", and also the definition+assignment operator, ":=". In the latter case, C++'s "auto" keyword is used to infer the type.
Closes #11.
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
:memo: Please visit https://cla.developers.google.com/ to sign.
Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.
- If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
- If you signed the CLA as a corporation, please let us know the company's name.
I'm planning to invest a significant amount of time on this project. But this CLA requires me to surrender my copyrights to Google. I understand the reasoning behind that, but that's a way to kill enthusiasm for outside contributors. Is there anyone I can speak with to clear a few questions?
By "copyright surrender", do you mean "license grant"?
IANAL, but I'm happy to try to get more clarification on this.
@lpereira : I spoke to an internal lawyer and he said:
We're getting a simple license. Which means we have the rights to use his contribution, but he retains all ownership rights to it, including the rights to patent it, sell it, or license it under another license to someone else. If he's still concerned, he should speak to an independent lawyer.
I hope that helps to clarify the CLA.
That seems OK. I've just signed the CLA, and will do the changes you've suggested. Thanks, @proppy.
CLAs look good, thanks!
Updated the PR. The vet error is a false positive; it's a Fprint() call, not a Fprintf() call, so there won't be any formatting directive.
@lpereira what do you think of implementing the test as direct unittest of the handleAssignStmt function, I was thinking to keep the file based test for actual arduino sketch.
The
veterror is a false positive; it's aFprint()call, not aFprintf()call, so there won't be any formatting directive.
Agreed that it's a false positive in this case. Any ideas how to avoid the entire CI always failing because of that one line, though? It'd be a shame to turn off vet checking completely just because of 1 false positive.
According to https://github.com/golang/go/issues/6407, this won't be fixed upstream.
So maybe using -printf=false is the best way to go? Thoughts? It's still suboptimal because it turns off printf checking everywhere... But better than no vet checks at all.
@proppy Sure, I'll do that. Still getting used to Go.
@shurcooL Maybe pass a better list to -printfuncs instead of -printf=false? I can see fmt.Fprint() being used a lot in this project, although there should be very few cases where % will be present in the formatting string.
Also, AFAICT, vet just offers some advice; I'm not sure if it's verdict provides ground to fail a build in the CI.