Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Rock has trouble with array return types #348

Closed
shamanas opened this Issue Dec 3, 2011 · 6 comments

Comments

Projects
None yet
4 participants
Collaborator

shamanas commented Dec 3, 2011

The following code works:

f: func -> SSizeT[] {
    return [1,2,3,4]
}

However, it causes rock to go nuts (ERROR Couldn't add { } after [1, 2, 3, 4] in scope.) when autoreturn is used, such as:

f: func->SSizeT[] {
    [1,2,3,4]
}
Member

nddrylliog commented Dec 3, 2011

Woha. That is going to be a nasty one. Also, should that even work (I mean run, not compile) ? The array would be stack-allocated, thus being deallocated when being returned... sounds messy.

What are you trying to do exactly?

Collaborator

shamanas commented Dec 4, 2011

Excelent point.
I was just going through the IRC archives and someone apparently discovered that issue but did not report it.

Contributor

ahamid commented Dec 4, 2011

This is probably the issue I posted, and is possibly due to the fact that I'm new to OOC. I did not know [] was a traditional stack-allocated array (and not perhaps just some syntactic sugar for a heap-allocated fixed-sized array). I switched to ArrayList which seems to be the right answer in this case. But the errors from Rock were confusing so I wasn't sure if I actually had a syntax or other error in the code.

Contributor

ahamid commented Dec 4, 2011

I guess ideally a warning would be emitted ("returning pointer to stack-allocated memory!"), but I think that would possibly require sophisticated escape analysis, and may not be warranted since there are already gc'd alternatives in the runtime lib.

Member

nddrylliog commented Dec 4, 2011

So :) Hi @ahamid, long time no see!

What's sure is that rock shouldn't throw the error we see here, which is an AST manipulation error (one of those Exception I put it "just in case", but I was pretty confident they'd never happen...) - in other words, never is today!

So, that AST manipulation bug should be solved first (after all that's what the issue is for), and then we'll see if we can emit a proper warning.

Collaborator

fasterthanlime commented Jul 10, 2015

The ArrayLiteral code is a clusterfuck btw :(

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