I'm not based in China, bro. You're the one who went around accusing random people of being advanced persistent threat actors, and now you can't even keep your story straight.
The "small string optimization" makes the strings harder to manipulate with `unsafe` code. However, being easy to manipulate with `unsafe` code is in fact a priority for most std types, so that they are easily understood, extended, rearranged, passed over FFI and then later reconstituted, etc.
You can tear apart these types and reassemble them very easily. For many C++ std types, you cannot do this.
The Rust calling convention is actually defined as unstable, so 1.79 is allowed to have a different calling convention than 1.80 and so on. I don't think designing one for the long term is a real concern right now.
Allowing developer control over calling conventions is also simultaneous with disallowing optimization in the case that Function A calls Function B calls Function C calls Function D etc. but along the way one or more of those functions could have their arguments swapped around to a different convention to reduce overhead. What semantics would preserve such an optimization but allow control? Would it just be illusory?
And in practice assembly has the performance disadvantage of not being subject to most compiler optimizations, often including "introspecting on its operation, determining it is fully redundant, and eliminating it entirely". It's not the 1990s anymore.
In the cases where that kind of optimization is not even possible to consider, though, the only place I'd expect inline assembly to be decisively beaten is using profile-guided optimization. That's the only way to extract more information than "perfect awareness of how the application code works", which the app dev has and the compiler dev does not. The call overhead can be eliminated by simply writing more assembly until you've covered the relevant hot boundaries.
Your experience is not perfectly transferable. JITs have it easy on this because they've already gathered a wealth of information about the actually-executing-on CPU by the time they generate a single line of assembly. Calls appear on the hot path more often in purely statically compiled code because things like the runtime architectural feature set are not known, so you often reach inlining barriers precisely in the code that you would most like to optimize.
This is a frankly ridiculous assertion given LKML's notoriously toxic history. Part of the problem is that overly-entitled maintainers can be as equally dangerous to actual progress in the project by stonewalling useful code on invented reasons that have never been applied to previous PRs and that the maintainer does not apply to their own commits.
You have not described a mechanism or API by which the compiler or programmer could enforce that only Leak types are on the stack and that a longjmp will not traverse `!Leak` types. And the only real way to get this would be to describe an interface that would have to be variadic to allow calling functions in general, as you would have to ensure that all args to a given `impl Fn*` are `T: Leak` for `T0` through `Tn`, and Rust currently lacks variadic generics. At that point, you might as well just do the same for `!Drop`.
It can be the case that people didn't feel that unions were a net positive from the 1960s~2000s and now, starting from somewhere in the late 2010s, have begun reconsidering whether unions are net positive. All that needs to change is conditions altering which make unions seem to be a net positive.
My remark was an observation based on the obvious public resentment, rather than necessarily an exhortation to do so. I promise you, I will not be so cagey and ambiguous when I actually call for someone's head on the chopping block.
Almost no one actually does test the unstable things. There's too much friction.
Almost no one actually gives us feedback on them. There's too much friction.
Things land on stable, people FINALLY actually mass-use them, the stable thing turns out to be busted, and THEN people overcome the friction to complain because they (rightly) fear it is going to be unfixable. Sometimes it is. Most of these have been very minor so far, and only affected things easily rolled back, but there will come a day when it is not so minor and not so easy to roll back. And nothing we can do in simulation or stress-testing on our end can replace contact with actual programs.
We're not making a typical "product" here. You can't think of it in typical product terms. We're making a programming language here. A contract, effectively, though not a legal one, as it is itself a system of expressing contracts. We cannot simply roll back things that are part of the language's contract in our stable releases if something is flawed, unless the flaw is SO dire as to result in one of the handful of situations that allows us to break it anyways.
The rustc driver for trusted PL/Rust prevents using the subset of the Rust language required to trigger those issues. Most of them are things that would have a hard time traversing the Postgres procedure call boundary, anyways, in a legitimate use-case, so this isn't expected to meaningfully affect actual user code.