[Vala] Dealing with bugs in the compiler

[Thomas Jollans <t jollybox de>]

Hi list,

We all know that Vala is not perfect, and every now and again, I hit a
bug in the compiler. I'm not talking about snags where something isn't
as I expect it, but about Vala generating C code that doesn't compile or
does improper memory management. As I know some of you also spend time
working on complex Vala projects, and I'm sure that you, too, will
stumble across some issue, I was wondering how you dealt with this kind
of problem, and whether we agreed on best practices.

Of course, I never immediately jump to the conclusion that the compiler
is doing something wrong. For me, once I have a good enough
understanding of where an error I don't understand occurs, the first
step is to try to write a simple, self contained, correct example that
reproduces the problem. This usually helps me understand the precise
nature of the issue I'm facing.

If, at this point, I have a short piece of code that causes problems I
don't understand, I go this very mailing list with it. There'll be
somebody here who understands Vala better than me and able to clarify.

If I do understand what's going wrong, I have to convince myself that
it's actually a bug in Vala before reporting it. Broadly speaking, this
could fall in one of four categories:
 * Explicitly documented behaviour being broken / missing
   (I don't think I've ever seen this myself)
 * Incorrect VAPI bindings
 * Valac generating incorrect C code that doesn't compile and link
 * Reference counting issues in code that does not explicitly call
   Object.ref() or Object.unref()

If it is a bug in Vala, after checking that it hasn't been reported
before, I file a bug against the compiler, attaching my reproducible
code sample. If I have different Vala versions available, I will test it
with multiple versions on the off-chance that it's a regression from a
previous version - this information could help the maintainers.

Those were the obvious steps - Everybody should be following them
anyway. Now, the interesting part - how to deal with a broken compiler
in your project. I do this: I add a workaround to my code (there's
always a way), and add comments to the workaround code explaining that
it is necessary due to a bug in Vala, the nature of the bug, and a link
to the bug report at bugzilla.gnome.org. This way, it's possible to
periodically check if code that shouldn't exist in the first place is
still necessary, or if Vala has been fixed and the workaround can be
removed.

What do you do? Do you take the effort to explain workaround in your
code? Or do you go straight to fixing Vala yourself? (good job, man!)
How broad a range of Valac versions do you try to support? I think I'm
currently "on top of things" enough to know when the most recent
relevant bug-fix in Valac was, so that's the number I specify as minimum.

At this point, I must say: the situation has vastly improved since I got
started with Vala in spring last year. Good job, my friends! The number
of ugly workaround constructions in my code that I'd like to kick out is
not zero, but it's a lot lower than it was a year ago.

Regards
Thomas

PS: I'm not sure what to make of the fact that several bugs I've
reported are still "UNCONFIRMED", with no comments, despite including a
simple, reproducible test case. They're mostly obscure, so I'm not
expecting a quick fix, but a "confirmed" or "cannot reproduce" would
still be reassuring. But no worries, guys, I'm not letting lack of
feedback stop me.