Outdated comment on managing the reserved stack size of wasm

[jayzhan211]

wasmtime/crates/cranelift/src/lib.rs

Lines 43 to 45 in 337c1ca

	// For more information about the tricky bits of managing the reserved stack
	// size of wasm, see the implementation in `traphandlers.rs` in the
	// `update_stack_limit` function.

There is no update stack limit func now.

It seems that the current stack size is computed directly when enter wasmtime?

wasmtime/crates/wasmtime/src/func.rs

Lines 1289 to 1309 in 337c1ca

	// Determine the stack pointer where, after which, any wasm code will
	// immediately trap. This is checked on the entry to all wasm functions.
	//
	// Note that this isn't 100% precise. We are requested to give wasm
	// `max_wasm_stack` bytes, but what we're actually doing is giving wasm
	// probably a little less than `max_wasm_stack` because we're
	// calculating the limit relative to this function's approximate stack
	// pointer. Wasm will be executed on a frame beneath this one (or next
	// to it). In any case it's expected to be at most a few hundred bytes
	// of slop one way or another. When wasm is typically given a MB or so
	// (a million bytes) the slop shouldn't matter too much.
	//
	// After we've got the stack limit then we store it into the `stack_limit`
	// variable.
	let wasm_stack_limit = stack_pointer - store.engine().config().max_wasm_stack;
	let prev_stack = unsafe {
	mem::replace(
	&mut *store.0.runtime_limits().stack_limit.get(),
	wasm_stack_limit,
	)
	};

This is the PR when update_stack_limit is removed.

I think the comment need to be updated or deleted.