Re: [Vala] Code generation bugs



On Fri, 2008-06-06 at 16:48 +0100, David Given wrote:
(a)

This code fragment:

void function(int a) throws IOError
{
        TestObject o = new TestObject();
        throw new TestError.FNORD("test error");
}

...compiles to:

[...]

That looks to me like the reference to o isn't being dropped when the
error gets thrown. Is this supposed to, er, not happen?

That's been fixed in SVN r1596.

(b)

This piece of standalone code:

using GLib;

class TestObject : GLib.Object
{
}

public TestObject o;

The TestObject class should be public if it's used in a public field.
valac should report an erorr in the case where the class is private, of
course.

(c)

This code fragment:

delegate int FPtr(int a);
int test(int arg)
{
        FPtr f = (a) => { return a + arg; };
        return f(arg);
}

...compiles to the following code:

static gint __lambda0 (gint a) {
        return a + arg;
}

static gint ___lambda0_fptr (gint a, gpointer self) {
        return __lambda0 (a);
}

static gint test (gint arg) {
        FPtr _tmp0;
        void* f_target;
        FPtr f;
        f = (_tmp0 = ___lambda0_fptr, f_target = NULL, _tmp0);
        return f (arg, f_target);
}

Note that __lambda0() is referring to arg, which is actually defined as
an argument to test(); this fails to compile. Now, I'm aware that this
sort of behaviour is one of the traditionally Really Hard things to
implement in a static language like C, but it probably shouldn't produce
bad code in quite this manner (putting, for example, 'public int arg' at
the top of your program will make it compile erroneously quite happily).

We'd like to add support for full closures as far as possible but it's
not there yet. At the moment you can only access fields of `this'. valac
should report an error message as long as it doesn't support access to
method parameters/variables but that check hasn't been added, either, so
far.

Jürg




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]