Method limit is not checked properly

[Mai-Lapyst]

The WrenVM currently has a kind hardcoded limit of Method names of 65535 due to the CALL_X opcodes take a u16 as argument into the WrenVM.methodNames symboltable. When creating a wren program that adds more methods than that, the number overflows and incorrectly uses wrong methodnames.

Test-script generation code:

code = ""
code << "class A {\n"
code << "  construct new() {}\n"
for i in 177..(2**16) do
  code << "  method#{i}() {}\n"
end
code << "}\n"
code << "A.new().method65536()\n"
File.write("method_limit.wren", code)

Resulting debug output (takes some time to parse everything):

      588246  LOAD_MODULE_VAR     24 'A'
      588249  METHOD_INSTANCE  65534 'method65534()'
65361: 588252  CLOSURE          65361 [fn 0x62d77f56c260] 
      588255  LOAD_MODULE_VAR     24 'A'
      588258  METHOD_INSTANCE  65535 'method65535()'
65362: 588261  CLOSURE          65362 [fn 0x62d77f56c3f0] 
      588264  LOAD_MODULE_VAR     24 'A'
      588267  METHOD_INSTANCE      0 '!'
65365: 588270  LOAD_MODULE_VAR     24 'A'
      588273  CALL_0              35 'new()'
      588276  CALL_0               0 '!'
      588279  POP
65366: 588280  END_MODULE
      588281  RETURN
      588282  END

Note that the last method declaration is wrongly created for ! and the call instruction is also wrongly for !.

[ruby0x1]

Thanks for the reproducible test and the issue! I'll take a look ✨

[Mai-Lapyst]

Thanks for the reproducible test and the issue! I'll take a look ✨

Hi, and thanks for the quick reply. I was also working on it, but wasn't quite into the sourcecode yet; however I now have opened a PR with an small fix to atleast get a compiletime error: #1194 . Another, more "longtime" solution might be to use an Variable-Sized integer for these opcodes so the vm could theoretically support the full u32 range...