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
rustcproject, a self-bootstrapping compiler that requires one run the build product to build its own
libstdin order to do much of anything
- To put it another way: does anyone deliberately build
rustcin 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
libstdto build is a crucial step in being able to do useful iterative development with optimizations turned off in the compiler.)
- (The use of
((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
rustcwho wants us to continue turning off optimizations (for the rustc and stdlib builds) when
--enable-debugis 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).