cast now works in VM in more contexts, behaving like in RT; eg: int|pointer <=> ptr T | ref T (eg: enables nimyaml at CT)

[timotheecour]

• continues what was started in VM: support importc var, ptr/pointer types, cast int <=> ptr/pointer #12877
• see tests: tcastint.testCastRefOrPtr

future work

• also handle casts involving tyCstring, eg cast[int](someCstring)

example use case

• after this PR nimyaml works in VM even with ref types, see how much work needed to make it work at compile time? flyx/NimYAML#70 (comment)

EDIT: and even with cyclic structures involving YAML anchors, see flyx/NimYAML#92 (comment)

(and after #15528 it works with const too)

• but obviously this is generally useful and makes more code work at CT (without needing to annotate with lots of when nimvm and custom workarounds)

[timotheecour]

ping @Araq , I've rebased to fix bitrot conflicts

[Araq]

Wait what?

[timotheecour]

It's the same as all the other pre-existing cast[ptr T](address)[] in derefPtrToReg, with T = TNode in this case.
The tests exercise all of this, and make CT behavior consistent with RT behavior.

[Araq]

But I don't mind that nimYaml doesn't work at compile-time all that much. I care more about my compiler not crashing in mysterious ways because "everything works at compile-time". These crashes at runtime are bad enough already but at least then you have valgrind and GDB and so many tools built for it.

How does the average Nim developer debug VM crashes? Previously this was the rule:

• The Nim compiler crashes. It's our fault. Always.

With your "improved" stuff:

• The Nim compiler crashes. It might still be your fault because you used cast at compile-time. Or maybe you used some dependency that does that. Come on, this is so much worse, I don't understand why you don't agree.

[timotheecour]

PTAL, all code comments addressed.

But I don't mind that nimYaml doesn't work at compile-time all that much

It's not just nimYaml. It's all the when nimvm: workaround that complicate user code/library code that I run into regularly; it's also nim secret and everything that depends on vm. This PR simply makes CT behave like RT in more places, for the same reason js backend should behave like c backend whenever possible: it allows code reuse.

Users shouldn't have to be forced into workarounds involving using gorgeEx + serialization/deserialization just to use some functionality at CT (or patching the compiler to add more one-off vmops logic that could be avoided).

cast is no more dangerous at CT than at RT, but preventing its use just because a user can misuse it just adds un-necessary limitations.

[Araq]

cast is no more dangerous at CT than at RT, but preventing its use just because a user can misuse it just adds un-necessary limitations.

But it is. At runtime you have tools to mitigate the problems of the lack of memory safety. At compile-time you have no such tools plus you might not even notice that the compiler is corrupted and produces wrong results. If you want cast in the VM, make it memory safe first. How to do that? The details currently elude me, but in principle it should be possible by adding some refcount and scope protection.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. If you think it is still a valid PR, please rebase it on the latest devel; otherwise it will be closed. Thank you for your contributions.