std: Remove misleading comments about segmented stacks

[richo]

These are implemented in asm, they're just not inlined.

Open questions are:

• Should I just inline them? They're.. big, but it seems as though this needs violates the #[inline(always)] gaurantees the others make.
• Does something (llvm?) provide these as intrinsics? The structure of this code suggests that we could be hoisting off something else, instead of flagrantly ignoring it like we do for power and mips.

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

The comment here is actually referring to how other architectures implement the functionality via the asm! macro. There's not reason for the architectures here to make a call to an external function other than that it's just tougher to translate them into inline assembly.

Should I just inline them?

Unless there's a big benefit to doing so, I'd avoid it for now. This code is probably on its way out anyway if we can move to stack probes and otherwise it's just somewhat of a maintenance burden.

Does something (llvm?) provide these as intrinsics?

Unfortunately, no :(

[richo]

So just for my understanding, it's referring to the fact that the implementations are succinct enough to be reasonable to asm! in here?

The way I interpreted it, it's suggesting that they are implemented in rust/c/whatever, which is not the case. If that's the case, I'll rewrite the comment to describe that the impls are pretty big and that they're in src/rt/arch/$arch/record_sp.S ?

[alexcrichton]

Sure, that rewrite sounds good to me!

[richo]

I want to have a closer look to make sure that this doesn't actually create a new frame, but I think this rewrite is coherent.

[alexcrichton]

@bors: r+ 506d5a8 rollup

looks good to me!