Add --uncheckedBehavior to customize the use of unchecked() contexts

[CountBleck]

This new option allows users to use unchecked() as usual, ignore it
entirely, and force unchecked contexts everywhere. Ignoring unchecked
is useful for debugging, and, if you're certain you want to accept the
risk, forcing unchecked could be beneficial for performance.

[MaxGraey]

I think it's better to have several options. Like:

• "uncheckedBehaviour": "default" (current scenario)
• "uncheckedBehaviour": "never" (ignore all unchecked access)
• "uncheckedBehaviour": "always" (use unchecked always)

wdyt?

[CountBleck]

I think it's better to have several options. Like:

* `"uncheckedBehaviour": "default"` (current scenario)

* `"uncheckedBehaviour": "never"` (ignore all unchecked access)

* `"uncheckedBehaviour": "always"` (use unchecked always)

wdyt?

I got this working, but the compiler doesn't want to bootstrap with --uncheckedBehavior always. For some reason, the Function's locals array doesn't contain ~lib/rt/common/OBJECT#get:rtId~this when compiling ~lib/rt/common/OBJECT#get:rtId using the Wasm variant. However, the corresponding Signature still has a this type. This leads to a negative length being passed to new Array(), which promptly aborts.

The last commit I added demonstrates this issue. When this is fixed, I'll force-push it away before this PR is merged.

[CountBleck]

After changing some code in the compiler, it appears bootstrap can compile all the tests using --uncheckedBehavior always.

[CountBleck]

This should be ready-to-merge, unless @dcodeIO wants to remove the {}= overload for Array.

[CountBleck]

I can probably remove that commit anyway due to #2586

[CountBleck]

Even with the unchecked operator removed, something is somehow broken.
I don't know how to fix this, and I'm not sure how to investigate this.

[dcodeIO]

The assert being hit is here (combining two flows that are attached to different functions). Interestingly this only fails for bootstrap:release but not for bootstrap:debug, which might hint at some sort of memory corruption. Perhaps, logging around the assert, seeing what the values are, gives some hints?

[CountBleck]

I just played around with git checkout -p 6c1b60d1fc9e8e3f78b50c0d1d3ce4ae0576c0ff src/*.ts and git restore --staged -p and git restore . and eventually got some results that I don't understand.

[CountBleck]

--disableUnchecked always works in bootstrap now, but omitting it causes breakage. Can we merge this without having --disableUnchecked always work in bootstrap?

[dcodeIO]

Given the problems observed with always, I wonder if this mode might generally not be a good idea. Would this all work (and be good enough) if we'd go back to a simple --noUnchecked option?

[CountBleck]

Given the problems observed with always, I wonder if this mode might generally not be a good idea. Would this all work (and be good enough) if we'd go back to a simple --noUnchecked option?

Going back to disabling unchecked would be fine, but describing the mode to be "unsafe" or "experimental" or just outright saying it breaks things should be warning enough.

@dcodeIO I'll do it if it's necessary.

[dcodeIO]

Given that unchecked will likely not stick around for long anyway, that there are unexplainable issues with the third mode, and if that's fine, going back to a simple --noUnchecked option (this name would fit well with other options) is what I'd prefer, yes :)

[dcodeIO]

Same assertion is hit in another PR (linked above), which is otherwise unrelated. Interestingly, the issue can only be seen on CI, and only on boostrap:release.

[CountBleck]

Bootstrapping with --uncheckedBehavior always definitely works now.

[dcodeIO]

Thanks :)