-
Notifications
You must be signed in to change notification settings - Fork 424
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
Dyno: Fix (callable variable, function) disambiguation #26454
Merged
DanilaFe
merged 13 commits into
chapel-lang:main
from
DanilaFe:fix-fn-callable-disambiguation
Jan 8, 2025
Merged
Dyno: Fix (callable variable, function) disambiguation #26454
DanilaFe
merged 13 commits into
chapel-lang:main
from
DanilaFe:fix-fn-callable-disambiguation
Jan 8, 2025
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…on cases Signed-off-by: Danila Fedorin <[email protected]>
For the purposes of stopping the search etc. Signed-off-by: Danila Fedorin <[email protected]>
Signed-off-by: Danila Fedorin <[email protected]>
Signed-off-by: Danila Fedorin <[email protected]>
Signed-off-by: Danila Fedorin <[email protected]>
Signed-off-by: Danila Fedorin <[email protected]>
Signed-off-by: Danila Fedorin <[email protected]>
Signed-off-by: Danila Fedorin <[email protected]>
Signed-off-by: Danila Fedorin <[email protected]>
Signed-off-by: Danila Fedorin <[email protected]>
2 tasks
riftEmber
reviewed
Jan 7, 2025
Signed-off-by: Danila Fedorin <[email protected]>
riftEmber
approved these changes
Jan 7, 2025
Signed-off-by: Danila Fedorin <[email protected]>
Signed-off-by: Danila Fedorin <[email protected]>
DanilaFe
added a commit
that referenced
this pull request
Jan 8, 2025
Closes Cray/chapel-private#6923. Depends on #26454, #26455 and #26456 because this causes more Domain methods to be resolved. The issue was in resolving code like this: ```Chapel class C { var x: int; var y: string; iter type myIter() { yield 3; yield 5; yield 7; yield 11; } } for i in C.myIter() do writeln(i); ``` Previously, dyno incorrectly set `isMethod` to be false, which made the `this` formal for methods to be incorrectly set. This PR adjusts this behavior to correctly track method calls when resolving iterator overloads. Reviewed by @benharsh -- thanks! ## Testing - [x] dyno tests - [x] paratest
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a precursor to another PR, which enables resolution of more of the domain module code, and finds this curious case that doesn't work in Dyno:
In production, we expect the call to
foo
in the body ofbar
to be a tuple element access, but dyno incorrectly attempts to perform full function resolution. This is difficult since the innerfoo
is not a function.In production, we resolve this problem by stopping the search for functions when we encounter a variable. In the case of an innermost variable, this is sound since variables are not overloaded or disambiguated (innermost is preferred). In the case of functions, this is sound because any functions defined after the variable during the search must be more distant in terms of scopes, and thus would be rejected in favor of "nearer" functions.
I chose to implement this behavior in Dyno, particularly because of a
TODO
by @riftEmber that seemed to be adjusting for this kind of behavior. To do so in the most performant way (i.e., without iterating over the list of found IDs to see if any were variables), I adjusted all the lookup procedures to return aLookupResult
instead of a boolean. This type is boolean-like (it supportsoperator bool
and|=
), but it contains two booleans, one of which is whether a variable was found. From there, I adjust the early-return logic (previously:innermostOnly && got
) to also handle the case of "I found a variable so I should stop looking".The only tricky aspect is detecting ambiguity, in which we found a function and non-function at the exact same place. We need to report an error when a variable and a non-variable were found since the last "return point" (last check for
innermostOnly && got
etc.). For this, I did fall back to an iteration: if a variable is detected in a scope, and there are several copies of that variable, it's almost certainly an error.Reviewed by @riftEmber -- thanks!
Testing