Change:
BOOL_OPTIONS="" VAL_OPTIONS="" <del> opt debug 0 "debug mode" </del> <ins> opt debug 0 "debug mode; disables optimization unless `--enable-optimize` given" </ins> opt valgrind 0 "run tests with valgrind (memcheck by default)" opt helgrind 0 "run tests with helgrind instead of memcheck" opt valgrind-rpass 1 "run rpass-valgrind tests with valgrind"

Discussion:
I build rustc from source with to get output from to chase down an ICE, and the resulting compiler is about 25 times slower than Nigthly on the same commit. (Servo’s script crate takes ~50 minutes instead of ~2 to trigger the same ICE, .) said on IRC: … which would explain the slowdown, but I didn’t find an issue filed for it, so here it is. This may be a Makefile issue: .
See and . The latter is specifically about optimizations and supposed to be fixed by . Is this still a problem (again) or are you building an older version of the compiler?
Oh you can explain it in different ways, see
should be good enough btw
I’m building 2015-04-25. I believe (which I had found) is not related but kind of is. I can try as suggests, but since lists and not I was lead to believe that enabling optimizations was the default. Is it not? Or is is tied to ? If so, why?
i think this may be "by design", according to discussion on and . Although then again it is not clear that there was consensus on that should imply (though my reading of the comments there that at least some of the participants were in favor of it having that effect). The intention, as I understand it, is that if you do , then you want an "ideal" environment for debugging, which for some people implies "do not let LLVM optimizations get in the way of my debugging experience." The problem with this reasoning is that bootstrapping takes an absurdly long time with . So in practice I do not see how one could realistically actually use without also including to override what it is doing today. (At this point I essentially always call via a driver script that passes explicit switches based on local filesystem context.) Anyway, I would not object if we went back and again decoupled the configure setting from the configure setting. (The argument for why "should" imply , as noted in the relevant , was that 2-3 flags for configure the build is too many, and therefore we wanted to identify two "modes": release mode and developer mode, and then choosing your mode via would yield the "ideal" experience for that mode. This all sounds fine, but I clearly take issue with the claim that is part of anyone's ideal developer mode.)

I can imagine the logic behind this, but in practice this is far from ideal. It’s only one data point, but here is how my thought process and experience went: I hit an ICE and I don’t know the exact cause Asking on IRC, I’m recommended to retry with There is no log output. I assume logging is disabled on my Rust build I decide to try making another build where they’re enabled. I look at . seems relevant, it probably enables logging. I note that is listed as an option, but is not. I assume this means my build will be optimized. This is what I want. The build is taking a while. I know Rust takes a long time to bootstrap and all, but this seems longer than usual. I go do something else. The build ended up taking just over 4 hours. I start building Servo with this new rustc. Cargo somehow decide to rebuild everything, even though I was careful to pick the same Rust commit. This takes another 2 hours, instead of the usual ~8 minutes. Every rebuild of just Servo’s script crate (where the ICE is triggered) now takes over 50 minutes instead of ~2.
Reopening: while documentation helps, I still think we should address the root problem here. See: (And maybe I'll just put up a PR changing the configure script to make it stop doing this.)
I agree with and that in practice you do not want to disable optimizations, and we should not do so without an explicit . This is extra true now that the debuginfo includes inlined functions fairly reliably even in optimized builds (at least on linux): getting a complete backtrace was the only reason I ever resorted to in the past, and it was always painfully slow.
This still seems to be the case, but hasn't been motivation to fix.
This bothers me every time someone accidentally does it, but I didn't even know this issue was open.
I still think we ought to change it. =)
Maybe we can force people to choose between and when is on. That way you can never misunderstand the role of . Like, when we trigger an error: Edit: I forgot we already switched to rustbuild, but you get what I mean
I'm still waiting for someone to come up with an usecase for an unoptimized compiler.

I thought you are the one who may find some clues. Doesn't it help you to decide a tricky behaviour of a compile result is caused by LLVM or rustc? I have no idea.
in theory yes, in practice I've yet to have such a bug (well, I did have one once, actually, but I didn't find it by turning off optimizations); in general an unopt compiler is just too slow to use.
Isn't this fixed by that is, these are all separate options now.
still exists and rustbuild reads .
also, regardless of the existence of , the code for building the bootstrap config from the still ties them together; see here: note in particular that bit about how the is established by the presence of the setting, and then that affects the default value for if it hasn't been explicitly established in the . My proposal is that we stop having the default here (solely for bootstrap builds) be affected by the setting for above it. (And update the docs/messages elsewhere in e.g. accordingly)
Note also that the doc comment for doesn't mention the influence of on its value. It gives this dire warning about having set to false, but the implication of the doc comment is that its always defaulting to :