New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[hl] use hl.NativeArray for Vector #11568
base: development
Are you sure you want to change the base?
Conversation
Another thing to address is that we're losing the |
Thanks to @Apprentice-Alchemist for telling me how to fix the array compare problem! HL is now green, and I'd like to merge this soon so that we can use I don't know what to do with the |
I don’t know what exactly you’re talking about, but maybe it’s worth making the function inlineable so that inline vector.sort(...) can inline the callback (not sure how faster it can be on different targets) |
Huh, I thought this didn't work on HL, but it seems like I'm wrong about that: import haxe.ds.Vector;
function f<T>(x:Vector<T>) {
trace(x);
}
function main() {
var v = new Vector<Int>(1);
f(v);
} This makes me reluctant to merge this because apparently I don't understand how |
It works, as long as you don't try to access the contents of the native array. |
Right, so the situation is actually even worse than I thought. Surely this should be caught earlier... Though to be fair, I also don't catch this on the JVM target and instead let it fail in the verifier with |
Your example gives me a proper error locally though:
Do you also get that segfault locally with recent HL? |
Access violation is the Windows equivalent of a segfault, looks like HL turns those into real exceptions somehow. |
Testing locally on my Linux machine gives
HL catches the segfault too but doesn't turn it into a real exception and just prints a stack trace before letting the default signal handler run. |
Yeah okay, I can't merge this before this is improved somehow because we would be going from working code to a segfault, which isn't the best upgrading experience... |
I don't think re-implement Vector directly with
|
I'll tell you how I got here:
I'm aware of the problems you point out, but note that Vector is supposed to be completely transparent, and its type parameters are supposed to be invariant. The problem is that this cannot be expressed in our type system at the moment, so the only way to catch this is at the generator-level, where These variance violations have been failing natively since the old Flash times, and I'm fine with that, but it shouldn't fail with an incomprehensible segfault. |
I think catching this in the generator would require inserting extra type checking during the typed expr -> bytecode phase in every place where there is a potential type "conversion". This can't be done in some kind of bytecode verification phase either because the native |
Meh, I expected arrays to know their element type. In that case I don't know how to properly manage this either. |
What about checking on array access/allocation instead, at that point the generator should be able to determine whether the element type is a type parameter. Lines 2001 to 2031 in 7217530
The example with Hmm. That wouldn't fix the |
The HL code to manage different types of Arrays is quite tricky.
So we shouldn't duplicate all of these for Vector, but it being an abstract with inline functions should work well ? |
I agree it should work for normal use-cases. The problem is that currently assigning |
I really think that Vector should be implemented on top of fixed array types on all targets where this is possible. I'm attempting this here for HL, which seems to work well enough on HL/JIT, but fails on hlc:
As @yuxiaomao points out, this has been reported before in #11468.
@ncannasse Any advice?