Hacker News new | ask | show | jobs
by matthewaveryusa 2177 days ago
Just out of curiosity, How does rust prevent the Gentoo issue of: you can compile with custom flags, but most projects have only been tested with specific flags and if you change them they will break the build, so really, no customer flags. It always starts off with custom flags and ends up ossifying to the default-only flags.
4 comments

Most of the flags tell the Rust compiler what strategies to use when producing machine code. Actual Rust code rarely looks at these flags, so correct interpretation of the program generally isn't affected by them.

Contrast this with C and C++, where it's common to #ifdef in an entirely different program depending on the flags.

It's certainly possible to do something like this in Rust, but in practice it's rare.

Based on my experience with feature flags on some projects that made extensive use of them Rust is definitely also vulnerable to this issue. In the projects also not all configurations and feature combinations had been tested, and some specific configurations caused compilation to break.

Good CI configuration can definitely help to catch these issues, but it's obviously an extra effort for projects to set up. The alternative could be to simply avoid feature flags and always compile everything, which depending on the project might or might not be the better option.

I'm guessing that when the parent says "custom options" they're referring to libraries providing their own customization options via "crate features" (https://doc.rust-lang.org/cargo/reference/features.html ). Not only do libraries have an incentive to test that their own feature flags work, but also these feature flags avoid combinatorial explosion (and are easier to test) because feature flags must be additive due to how Cargo is designed: every feature flag must function the same even in the presence of any combination of the rest (flags must not be exclusive with each other).

On the other hand, I'm guessing that by "custom flags" you're referring to compiler-level flags that influence codegen, which rustc doesn't have that many of, and most of the ones that rustc does have are for controlling things that people might reasonably expect to be nontrivial work to change in the first place (e.g. linker/symbol options, cross-compilation/platform options, LLVM/gritty optimization/instrumentation options). Of the rustc codegen options that ordinary users might want to play around with, I see only two: one for turning off arithmetic overflow checks (which makes all integers act like their overflowing equivalents from the stdlib), and one for determining the general strategy of what happens when a panic occurs. The latter is unlikely to cause problems because the default behavior is a superset of the configurable behavior, and for the former any silent problems in misconfigured users would manifest as panics for everyone else, so there's a good chance the problem would be fixed upstream regardless.

I meant basically all the stuff the other three comments said :)