Warn when trying to `isolate` reference types in `refc`

[arnetheduck]

Nim Version

2.2.4

Description

Calling isolate is meant to isolate all properties of the instance making it safe for moving to another thread - reference types are not safe for such moves since they implicitly reference the thread-local heap - ie they are not isolated in that sense.

This creates problems when refc users accidentally, or through the use of a library, try to isolate instaces of types that somewhere in their graph contain any heap-allocated type.

Notably, isolating non-heap types is safe and should not warn - this way, code that targets both refc and orc can work for non-heap types without further modifications - in refc it is after all common to pass ptr and other non-heap types across boundaries.

Current Output

Expected Output

Known Workarounds

No response

Additional Information

No response

[arnetheduck]

See also status-im/nim-taskpools#49 which implements a subset of this feature - in particular, it does not traverse ptr types to find deeply nested heap types - a type like ptr string must result in a warning!

[Araq]

Wait what? ptr string is always "I know what I'm doing" everywhere else in Nim.

[arnetheduck]

it's also doesn't conform to the intent of isolate in particular, and specially not with refc - ie it's just as wrong to pass ptr string to another thread as ref string and I can't think of any correct code that would benefit from that - besides, it's a warning - could be turned off if someone wants to actively do this.

I would argue that its UB for ORC too (due to non-atomic ref counting) and we could warn about it, but that's a separate issue I think (the focus here is on refc). hmm.. or maybe one can hide all refcount operations in locks and then it's safe:ish in orc - I don't know actually - for refc however, it's just wrong and no locks can possibly help you make such code correct