Compiler bug: fails on "for k,v in global_table.pairs(t)"

[ewmailing]

I found a bug with the Pallene compiler when trying to use a for in loop with a pairs function.
In my case, the pairs function was passed into Pallene from Lua and stored in a global table.

It seems that Pallene can't handle the g_luaFuncs. part

	for k,v in g_luaFuncs.pairs(t) do

	end

It gives the traceback:

lua: ./pallene/to_ir.lua:364: attempt to index a nil value (field '_def')
stack traceback:
	./pallene/to_ir.lua:364: in method 'convert_stat'
	./pallene/to_ir.lua:308: in method 'convert_stats'
	./pallene/to_ir.lua:317: in method 'convert_stat'
	./pallene/to_ir.lua:730: in method 'convert_func'
	./pallene/to_ir.lua:693: in method 'convert_stat'
	./pallene/to_ir.lua:271: in function <./pallene/to_ir.lua:219>
	(...tail calls...)
	[C]: in function 'xpcall'
	./pallene/trycatch.lua:64: in function 'pallene.trycatch.pcall'
	./pallene/to_ir.lua:46: in function 'pallene.to_ir.convert'
	./pallene/driver.lua:83: in function 'pallene.driver.compile_internal'
	./pallene/driver.lua:107: in local 'f'
	./pallene/driver.lua:207: in function 'pallene.driver.compile'
	./pallenec:48: in local 'compile'
	./pallenec:130: in main chunk
	[C]: in ?

This only happens with the C generation, while --emit-lua does not have a problem.

As a workaround, Pallene can handle this:

	-- Pallene can handle this:
	local my_pairs = g_luaFuncs.pairs
	for k,v in my_pairs(t) do

	end

parse_pairs_bug.pln.txt

Attached is a complete .pln module to test against.