intrinsics for trivial functions

[graydon]

In particular:

• incrementing a pointer (ptr::offset)
• Casting a pointer (cast::transmute)
• Possibly: running drop glue (cast::forget)

It's worth measuring to be sure but I believe the amount of code we generate to call the numerous monomorphic instances of these functions may be substantial. Moving the "intrinsic" recognition-point up just a touch might be worthwhile, though this is (as @pcwalton points out) a slippery slope that leads towards ever more ambitious "optimization in the frontend".

[brson]

Let's please do this in a way that doesn't expose the intrinsicness of these functions, e.g. the docs shouldn't reveal that cast::transmute is actually a reexport of unstable::intrinsics::transmute. I guess this could be done by making cast::transmute a lang item that just decays into the transmute intrinsic during codegen. Then of course the actual "rust-intrinsic" intrinsic wouldn't need to exist, so maybe we'll end up with another class of intrinsics. We could also just make rustpkg not treat "rust-intrinsic" functions as special then declare the transmute intrinsic where cast::transmute is now. Would be nice to have standalone decls for that: extern "rust-intrinsic" fn transmute(...);.

[Thiez]

Isn't the point of cast::forget to not run drop glue?

[thestinger]

Closing in favour of #10008.