Skip to content
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

Rock can't pick up generic type info from the typeargs of the return value of closure #921

Closed
alexnask opened this issue Jul 29, 2015 · 8 comments
Assignees

Comments

@alexnask
Copy link
Collaborator

I know, quite the title.

Here is what I mean:

/* THIS WORKS */

foo: func <T> (c: Cell<T>) { T name println() }
foo(Cell new(42))

/* THIS WORKS TOO */

foo: func <T> (f: Func -> T) { T name println() }
foo(|| 42)  

/* THIS DOESN'T */

foo: func <T> (f: Func -> Cell<T>) { T name println() }
foo(|| Cell new(42))

The above fails with error Missing info for type argument T. Have you forgotten to qualify foo<T> (f: Func () -> Cell), e.g. List<Int>? (btw, this error message is pretty misleading to beginners since explicitly qualifying functions, rather than types, is illegal in ooc)

@alexnask
Copy link
Collaborator Author

That is harder to fix than expected, ACS's get their return type from the function type in the call's function definition, so the closure is resolved to be of type Func -> Cell<T> and trying to fetch it from there obviously returns T.

@alexnask
Copy link
Collaborator Author

I wonder why the Func -> T case works though...

@fasterthanlime
Copy link
Collaborator

@Shamanas Realtypizing does pick up on quite a few cases, apparently Func -> Cell<T> wasn't one of them, but it shouldn't be too hard to add.

@alexnask
Copy link
Collaborator Author

I tried adding it last night but I got stuck because I am apparently getting Func -> Cell<T> as the type of the argument itself (not the function type in the functiondecl), which seems weird.
I'll be on it a bit later, I just need to reintroduce myself into rock gently <creepy smile>

@fasterthanlime
Copy link
Collaborator

getting Func -> Cell<T> as the type of the argument itself

Ah.. maybe the function's returnType is being realtypized, but not the function's type (if you see what I mean)

@alexnask
Copy link
Collaborator Author

Just for reference (so I don't forget and I fix this after going to the beach :P), I was assuming the return type of the function pointer was set to the inferred type but there is a special field, inferredReturnedType, which should work (I changed this back on my other PC and it resulted in crashes on some test programs, probably didn't do correct null checking)

I wonder whether BaseType searchTypeArg will work for "just" T so I can use the same code for -> T and -> Foo <T, K, V, ...>

Will probably fix that later, perhaps tomorrow morning in the worst case scenario.

@fasterthanlime
Copy link
Collaborator

after going to the beach :P

who says ooc devs have no life!

perhaps tomorrow morning in the worst case scenario.

famous last words, but the rest of your post is promising.

@alexnask alexnask self-assigned this Aug 1, 2015
@alexnask
Copy link
Collaborator Author

alexnask commented Aug 4, 2015

searchTypeArgs doesn't actually work in this case, because it obviously looks into the type's ref to find the typearg name you requested.

Instead, we should be able to provide two types, one unqualified (or partially qualified) and one fully qualified and extract a type arg from there.

This should work for all types though, not just "base" types, I guess I'll write something in typeAnalysis

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants