Fix recent JVM breakage (Rakudo::Unicodey)

[usev6]

No description provided.

[lizmat]

So not even an my int @a works in the setting on the JVM backend? Even that late in the setting?

[lizmat]

I've just pushed 496f986e6c in the hope it will stick on the JVM backend. If it doesn't, let me know, and I'll make it use an untyped array. Thing is that I will need do make all of the nqp::shift_i occurrences backend specific :-(

[usev6]

So not even an my int @A works in the setting on the JVM backend? Even that late in the setting?

I'm afraid that is the case. As far as I can see native arrays are mis-compiled into non-native arrays in the setting.

So, after 496f986e6c the JVM backend builds, but method ords for strings does not work:

$ ./rakudo-j -e 'dd "foo".ords'
VMArray representation does not implement push_native
  in block <unit> at -e line 1

Thing is that I will need do make all of the nqp::shift_i occurrences backend specific :-(

Do you refer to upcoming changes? Because for now things seem to work if an untyped array is used (as in 6014cfa).

$ ./rakudo-j -e 'dd "foo".ords'  ## with an untyped array and without nqp::push_i
(102, 111, 111).Seq

[lizmat]

Hopefully fixed with b88e1ca3bf Please close this PR if so :-) Thanks for the nudging and the PR!

[usev6]

It looks like we finally found a solution: #4293 -- and it doesn't even require many quirks.

The main discovery for me is that

my int @array;

is miscompiled in the setting (on the JVM backend, that is), while

my @array := array[int].new;

seems to work. That's good to know.

I'm closing this PR.