Why is --enable-debug implying --disable-optimize for rustc

internals
1

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 #![no_std]?
    • (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 --disable-optimize mode.

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).

2

FWIW I did the change that made --enable-debug behave the way it does now, but the intent of that change was to fully optimize release builds, not to do anything in particular with debug builds, so if debug builds are wrong I don’t have any opposition to changing them.

3

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.