fix issue resolving overload with polymorphic arguments when passed …#1496
Merged
Conversation
Collaborator
|
I'm not 100% sure, but if it's breaking other tests like that it's probably intended to work like this. My guess is it's something like it's not correctly recursing down to realise it should be a This should be a similar test case that demonstrates the same problem which should make debugging easier. package test
Bar :: struct{}
bar_ptr :: proc(value: $T) -> ^T {}
bar_pass :: proc(value: $T) -> T {}
main :: proc() {
b := bar_ptr(Bar{})
c := bar_pass(b)
} |
704e94c to
40be398
Compare
… pointer from another function resolves DanielGavin#1495
clone_node does currently ensure derived_expr or derived_stmt are kept in sync with derived, so they are not necessarily correct.
40be398 to
e2c46ee
Compare
Collaborator
|
Thanks! Works well for me. |
This file contains hidden or 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
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.
…a pointer to a generic from another function
Attempts to fix #1495
The problem seems to be that during
resolve_generic_function_symbolthe parameter resolves to the type without the pointer, assymbol_to_exprdoesn't retain that information. I am not certain if that is intended. The changes in this pull request change that, but it breaks several other tests, and causes the server to crash.Is there another mechanism by which this information should normally be retained, or is it an oversight of
symbol_to_expr?