Open bys1 opened 1 year ago
Thanks @bys1 ; this is worth a lot to me.
The ASM library that we use to assemble the bytecode is notorious in not providing error messages at all. This is to optimize for speed.
Flybytes surfs a little bit differently. We try to provide error messages if we can do this in O(1), so constant time overhead wrt to size of the program.
So any small and fast check we can do, or diagnosis after an exception, let's do it.
Finally, some JVM code just works even though it violates Java's type system. I'd like to keep it that way such that more code can be generated for DSLs than for Java. In particular some methods can be called even though the static type of an object does not align, but also some instructions implicitly coerce datatypes, saving precious stack operations. Here we have to tred carefully, for example by collecting warnings rather than bailing out.
What is weird, though, is that the decl in the loop gives the following error
This is caused by doubles taking up more stack slots than integers do.
I've been thinking about two alternative solutions:
The first is problematic for several reasons:
The second solution appeals to me:
Got another error when trying to compile a class. This stuff is horrible to debug, but after messing around for a while I came up with a small example that can reproduce the error:
The error does not occur when removing the while loop (moving the body of the while loop out of the loop). So the following program compiles without errors:
After my brain cells had recovered a bit from debugging, they discovered that this was an error on my side - Of course, using a double as array length (or index) is not possible, and an integer should be used. Using
iconst
instead worked. What is weird, though, is that the decl in the loop gives the following error:However, the decl without loop in the second code snippet compiles fine, although it is equally as wrong as the first one. Why is this the case? Maybe this is not really a bug, but it is certainly weird, because it made me think that the loop itself was problematic, while that was not the case at all.
Second question: Would it be possible in any way to give more descriptive errors in situations like this? Something like "type double cannot be used for array size/index" or even a more general error like "integer expected, double given" would be much more useful than a Java ArrayIndexOutOfBoundsException with no Java stack trace.