Open PallHaraldsson opened 1 year ago
Yeah, that's because we don't have libjulia, so no error handling. If someone wants to make a PR to try turning it on and using the new error override mechanism from StaticCompiler, we could try it at some point.
The merged PR you link to is on error handling. I scanned the code, but does it mean it works already? Then bounds-checking too? And if not bounds-checking (but error handling works) then why not? I didn't have in mind fixing error handling (e.g. good stack trace) in general, just if out-of-bound panic()
, rather than if .. throw ..
. Anyway, the logic likely belongs in the other repo, also for full error handling. But the docs here and there need to be synced, I'll fix some (other) inconsistencies.
So that PR means that people can implement overrides to catch errors, potentially including out-of-bounds errors. For common errors additional rules could be implemented either here or there, but the override functionality is quite new and would probably require some trial and error.
Turning @inbounds
off / enabling normal @inbounds
functionality on this end would also be a bit nontrivial given the current implementation -- it might actually be a bit easier to just implement our own error message and exit code for out-of-bounds indexing of StaticTools types internally within StaticTools if that is something we generally want.
"Consequently,
@inbounds
is always on for" why is that? I'm guessing because of exception handling, and it not supported in general.Since it's so common to NOT us
@inbounds
, would it be possible to have it but replace it in part, have the beck and just "panic", bomb somehow when you would have thrown?