internal XElem? findFront(XElem e)
{
frontmatter := e.elems.eachWhile |x|
{
log.debug ("name=${x.name}") // without this line it compiles OK
if (x.name == "frontmatter")
return x
else
return findFront(x)
}
return frontmatter
}
causes an internal compiler error (mercurial tip):
the compiler complains of Must return a value from non-Void method but return is not allowed here so one have to rewrite everything as
frontmatter := e.elems.eachWhile |x|
{
log.debug ("name=${x.name}")
return x.name == "frontmatter" ? x : findFront(x) // return ok
}
brianThu 25 Feb 2010
Promoted to ticket #995 and assigned to brian
There is some bug in the compiler there.
You can't use return in it-block to be make it crystal clear what you are returning from (we've had some previous discussions on that topic). So if you want to use return then you need to use normal closure syntax.
katoxThu 25 Feb 2010
You can't use return in it-block to be make it crystal clear what you are returning from
I wasn't sure if it wasn't due to some nasty case. Thanks for reminding me. Also, I'm glad that we don't have non-local returns - the more I'm getting used to closures the less I like that idea.
brianTue 23 Mar 2010
Ticket resolved in 1.0.52
Fixed ClosureExpr.collapseExprAndReturn to ignore non-return statements
katox Thu 25 Feb 2010
I found out that
causes an internal compiler error (mercurial tip):
If rewritten as
it works fine.
Sidenote: What was the reason disallowing
return
init
-blocks? No big issue but it behaves a bit strangely. Going fromwhich compiles fine to a debugging version of
the compiler complains of
Must return a value from non-Void method
butreturn
is not allowed here so one have to rewrite everything asbrian Thu 25 Feb 2010
Promoted to ticket #995 and assigned to brian
There is some bug in the compiler there.
You can't use
return
in it-block to be make it crystal clear what you are returning from (we've had some previous discussions on that topic). So if you want to usereturn
then you need to use normal closure syntax.katox Thu 25 Feb 2010
I wasn't sure if it wasn't due to some nasty case. Thanks for reminding me. Also, I'm glad that we don't have non-local returns - the more I'm getting used to closures the less I like that idea.
brian Tue 23 Mar 2010
Ticket resolved in 1.0.52
Fixed ClosureExpr.collapseExprAndReturn to ignore non-return statements