[PATCH] YJIT: Bail out if proc would be stored above stack top

	Fixes [Bug #21266].

Credits to @rwstauner for noticing this issue in GH-15533.

Previously, the chain_depth>0 version of setlocal blocks did not
update the type of the local variable in the context. This can leave
the context with stale type information and trigger or lead to miscompilation.

To trigger the issue, YJIT needs to see the same ISEQ before and after
environment escape and have tracked type info before the escape. To
trigger in ISEQs that do not send with a block, it probably requires
Kernel#binding or the use of include/ruby/debug.h APIs.

[Backport #21772]

Fixes: [Bug #21707]
[AW: rewrote comments]
Co-authored-by: Alan Wu <alanwu@ruby-lang.org>

Previously because we did a stack_push before ccall, in some cases we
could end up pushing an uninitialized value to the VM stack when
spilling regs as part of the ccall.

Co-authored-by: Luke Gruber <luke.gru@gmail.com>

Previously, YJIT returned truthy for the block given query at the top
level. That's incorrect because the top level script never receives a
block, and `yield` is a syntax error there.

Inside methods, the number of hops to get from `iseq` to
`iseq->body->local_iseq` is the same as the number of
`VM_ENV_PREV_EP(ep)` hops to get to an environment with
`VM_ENV_FLAG_LOCAL`. YJIT and the interpreter both rely on this as can
be seen in get_lvar_level(). However, this identity does not hold for
the top level frame because of `vm_set_eval_stack()`, which sets up
`TOPLEVEL_BINDING`.

Since only methods can take a block that `yield` goes to, have ISEQs
that are the child of a non-method ISEQ return falsy for the block given
query. This fixes the issue for the top level script and is an
optimization for non-method contexts such as inside `ISEQ_TYPE_CLASS`.

These `#[cfg(feature = "disasm")]` were unnecessary and we can provide
the information like ruby source location regardless of the availability
of capstone.

YJIT: Add more information to an assert message in jit_guard_known_class (#14480)

---------

Co-authored-by: Alan Wu <XrXr@users.noreply.github.com>

Backport of 7e733ca55168e3b1f10b685f6e9a52cf1deb5aff to
fix [Bug #21514].