# [derive(Clone)] Is Broken

Proc macros are implemented in an unsafe way because they run arbitrary code during compilation and access any files. I do not like it.

Also I think it would be better if they operated with reflection-like structures like functions, classes, method rather than tokens - they would be easier to write and read.

I agree in principle but also there's a lot of worth in having them do that in certain cases, and build scripts and the like already have that anyway.

Achieving a perfect world where build tooling can only touch the things it really needs is less of a toolchain problem and more of an OS hardening issue. I'd argue that's outside the scope of the compiler and language teams.

This is often overlooked. No, I don't want random cargo package to run RCE's on my machine. And there's just so many; in terms of bloat, the dependency trees are huge, rivaled only by Nodejs, if I'm being honest. I have to build some Rust stuff once in a while (mostly Postgres extensions) and every time something goes wrong it's a nightmare to sort out.

I never have these issues. Is the postgres driver a C wrapper? that's where things tend to fall apart.

Yeah, they would often claim that C API is at fault, but believe it or not, blaming Rust just as much. I've had an interesting discussion with pgrx people: https://github.com/pgcentralfoundation/pgrx/issues/1897#issu... to quote @workingjubilee

> Rust has formally rejected the notion that any function can return twice. Even LLVM has no special knowledge of the name of "sigsetjmp" or "setjmp", only that some functions can return twice.

> Thus, when you call sigsetjmp or setjmp from Rust, Rust doesn't believe that you called a function that can return twice. The Rust compiler refuses to annotate it with the required LLVMIR annotation. Thus LLVM sees a call to sigsetjmp that it believes cannot return twice... it's just an ordinary function that someone named "sigsetjmp" because they have a sense of humor. What LLVM does next is between itself and whatever gods that compilers believe in, and we have no more voice in such a matter.

In this particular case, it's hardly the fault of a "C wrapper."

Sure looks like it is, indeed, a C problem. Which checks out with my experience, the only time I had a crate fail to build in all these years it was C underneath and of course C is just anything which happened to compile and seemed to work. As an ex-C programmer I guess I sympathise, none of the non-trivial C I wrote 10-20 years ago actually builds out of the box on today's systems that's just how C is, so why would Rust magically fix that.

I mean... yeah? Rust explicitly doesn't allow longjmp or related machinery, at least not in any way that works well with the Rust VM.

And for good reason. That's been a wart and a hack since the day it was created. I'd say this is a _good_ thing.

My issue with it at the time had to do with... how to put it... simply build the extension, & carry on with my life. Version after version it would build alright, and then suddenly, boom, it doesn't work no more. Okay, I understand that perhaps ppc64el is not the most popular architecture, and some things aren't easily portable, but this otherwise mirrors my experience with Rust programs. It's always requiring the latest version of everything. The recommended installation path involves sudoing shell scripts over network, and I'm sure Rust people love it, salivating over new versions and features that come along, constantly staying up to date, but to the rest of us normal people dealing with Rust software is a chore.

Cmake is a huge quality-of-life improvement all things considering!