A recent PR https://github.com/rust-lang/rust/pull/24902 finally drove me over the edge.
I really want us to revisit a recent change we made to the build system. Rather than continue with the status quo, I think we should just having
--enable-debug stop disabling optimizations when building rustc itself.
- I understand the logic behind having
cargo --developer (or whatever the single option is in that context) disable optimizations. Cargo has its own conventions and its own larger audience to address.
- but I fundamentally do not understand why that reasoning is being equally applied to the
rustc project, a self-bootstrapping compiler that requires one run the build product to build its own
libstd in order to do much of anything
- To put it another way: does anyone deliberately build
rustc in debug mode, with optimizations deliberately disabled, who is not also focusing solely on doing builds of tiny test programs with
- (The use of
#![no_std] is crucial -- avoiding having to wait for
libstd to build is a crucial step in being able to do useful iterative development with optimizations turned off in the compiler.)
((Perhaps the actual goal that was not specified carefully enough was for the stage1 compiler to be built with
-O but the stage2 compiler built without
-O ... that is also a viewpoint I could understand. But it is not where we are standing today.))
So, can someone clue me in here?
- Is anyone actually developing
rustc who wants us to continue turning off optimizations (for the rustc and stdlib builds) when
--enable-debug is turned on?
- If so, please respond! Tell me!
- I have seen very little evidence that one can effectively hack on the compiler when in
Because if we are all just passing
--enable-optimize to configure here, then something is wrong.
Relevant links (to show that I have seen and participated in some of the previous arguments on this topic).