-
-
Notifications
You must be signed in to change notification settings - Fork 419
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
Inference of lambda type and array element type from an antecedent (RFC 45). #2168
Conversation
This one is in the final stages of cleanup work before preparing to merge. I've tried to imagine and test for all the cases of this, but invariably I will have missed some cases. We can clean up the cases I missed later, as they come up. |
0d65065
to
9a2145c
Compare
9a2145c
to
460d5e4
Compare
Hm, nevermind - I've come across a case that I didn't handle already, so I'm going to take a look to see if it can be handled. |
src/libponyc/expr/array.c
Outdated
@@ -27,6 +272,13 @@ bool expr_array(pass_opt_t* opt, ast_t** astp) | |||
told_type = true; | |||
} | |||
|
|||
if(!told_type && (ast_childcount(elements) == 0)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can use the size
local instead of the duplicate call to ast_childcount
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call. Fixed in 943c1ba.
src/libponyc/expr/array.c
Outdated
#include "../type/lookup.h" | ||
#include "ponyassert.h" | ||
|
||
static ast_t* build_array_type(ast_t* scope, ast_t* elem_type, token_id cap) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a particular reason to use this new function instead of type_builtin_args
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't know about that function.
In 943c1ba I refactored build_array_type
to use type_builtin_args
as part of its implementation.
src/libponyc/expr/array.c
Outdated
{ | ||
for(ast_t* c = ast_child(ast); c != NULL; c = ast_sibling(c)) | ||
find_possible_element_types(opt, c, list); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd feel more comfortable with a break
or return
here, to avoid problems in future refactorings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call. Fixed in 943c1ba.
I found and fixed some more edge cases. I also addressed @Praetonus' review comments. This is ready for a final review. |
@jemc looks like this needs a rebase? |
@SeanTAllen - I'm not sure what you mean. As long as we merge with the squash-and-merge feature of GitHub, it will only show as one commit. In other news, I'm applying the "DO NOT MERGE" label on this again because it's hitting an issue in the changelog tool compilation. |
@jemc i was referring to the "This branch cannot be rebased due to conflicts" |
The Linux LLVM 3.9 builds (both debug and release) are hitting an assertion failure in the type inference code when building pony-stable. |
These calls were incorrect anyway, because it wasn't a subtree - the opt frames were not the right frames, causing subtle issues in some cases.
Removing the "DO NOT MERGE" label - if this passes CI, it's good to merge. |
@jemc Travis is showing the following error on all builds:
|
This now passed all Travis builds except the last build for OSX, which had a Travis-caused error. I restarted that one build, so here's hoping it finally passes this time. |
🎉 |
@jemc can you write up release notes for this so i can include with the release? |
@SeanTAllen - here's a shot at some helpful release notes: This release includes significant improvements to type inference for array literals and lambda expressions when the type of the expression has an unambiguous antecedent (such as the "left side" of an assignment, the parameter signature of a method call, or the return type of a method body), including the following improvements:
For more information, see RFC #45. |
@jemc is this a breaking change? would we be doing 0.19.1 or 0.20.0? |
@SeanTAllen - it's not a breaking change. If this breaks some working code, that would be a bug to be fixed. That said, I think we've been bumping the second number for both breaking changes and new features, here in the pre-1.0.0 days. That is, I think we use the third number for representing bug fixes. I could be wrong though. |
@jemc i havent been bumping for new features at this point, only breaking changes. |
Resolves #2094.