build the compiler with --cfg debug

[brson]

I hit a trans bug in stage0 today and I have pretty much no way of figuring out what's going on because it has no logging.

[emberian]

+1

[pnkfelix]

@brson you're just talking about a special configure setting for building the snapshot compiler, right? (As opposed to changing the defaults for the configure script across the board?)

[alexcrichton]

I think that this would be better implemented with --cfg ndebug instead of --cfg debug. Almost everyone expects debug output by default, and this way you have to explicitly opt-in to the faster version. We could configure the bots to pass --cfg ndebug to speed them up, but almost all devs want --cfg debug.

Also the --enable-optimize flag to the configure script should pass --cfg ndebug I imagine as well.

[pnkfelix]

I'm still trying to figure out what the scope of this bug actually is; as I asked @brson, is this request merely for a change to how the snapshot rustc is built? That seems like something we can (and should) do easily.

But, allowing for a bit of scope creep beyond that for a moment... :

@alexcrichton When you say "Almost everyone expects debug output by default", do you mean rustc-hackers expecting debug output from invocations of rustc, or do you mean Rust programmers expect debug output from the programs that they compile?

For Rust programmers, I support making the expected common case, whatever it may be, as painless as possible, which could imply switching to --cfg ndebug. I'm not sure if I have the same paternal mindset towards rustc-hackers on their own.

Also, are you suggesting that people write #[cfg(not(ndebug))] to guard their debug-only code? Or are you suggesting that --cfg ndebug somehow turn off cfg(debug) setting that is otherwise on by default? (These are the two immediate options that I see for implementing ndebug, and neither one really appeals to me.)

As you probably have inferred, I personally don't mind the current --enable-debug and --cfg debug setup (but then again I'm used to having wrapper scripts around configure that infer the flags from my build directory names).

[alexcrichton]

I was intending more of rust programmers in general because this affects the output of debug!. I would expect that to print by default (without me having to do anything different than invoking rustc.

That being said, you're right about now "debug code" is hidden behind #[cfg(not(ndebug))] which not only looks silly but it's nearly impossible to understand. I also agree that this shouldn't affect whether the --cfg debug variable should also get set.

Although #[cfg(debug)] makes perfect sense to me, having debug! print by default makes more sense to me, so I think that we should favor debug!.

The problem that I've seen is that it's very easy to forget the --enable-debug if you're not using scripts (which perhaps I should...), but I'm also worried rust binaries in general.

[pnkfelix]

@alexcrichton so it looks to me like you have landed PR #9278 and are in the process of proposing PR #9385 . Its unfortunate that neither of those Pull Requests mentioned this ticket, so I didn't get a direct notification.

From skimming PR #9278, it looks like you simply accepted the #[cfg(not(ndebug))] annotations, despite your agreement with me above that it looks silly? Am I right about this?

Finally, PR #9278 seems to contradict directly the intent of PR #7822. I do not mind having the debug! macro enabled by default. But from what I read, @pcwalton had asked for debug! to be turned off by default; did he sign off on this?

(Sorry if the above note sounds curt; maybe there had been consensus amongst the group in California and I simply missed it since it was not logged here.)

[pnkfelix]

(BTW Its certainly possible that I misunderstand the intended scope of #7822. There's not much context there to work with.)

[pnkfelix]

After some reflection, it does not seem like a terrible burden to require end-users to opt into ndebug in order to get the faster debug!-free object code.

I'm still not a fan of the #[cfg(not(ndebug))] annotation, but I do not have a better suggestion besides going back to having debug! depend on --cfg debug. (I can go either way on that.)

I do not know whether @pcwalton's interest in conditionalizing debug! was for servo execution speed or for rustc bootstrap times. In hindsight, it was probably for servo; but I guess they can turn on ndebug.

So, I'll stop making noise about this.

[alexcrichton]

Gah, sorry about that! I totally forgot to cc this bug. There wasn't really an "official" consensus per se, more of a general feeling of agreement, and I'd be ok with reverting these in the meantime if there are strong feelings to be had.

That being said, I don't think that this really contradicts #7822. It's more of another way to go about solving it. In #7822, the compiler would be "fast by default", and now it's just "verbose by default, which may not be fast". For performance, we still have the option to omit the debug! statements (which was the goal all along).

I also still agree that cfg(not(ndebug)) is confusing, but as you've mentioned I'm having a difficult way of getting around that. The key idea that I want to have is that debug output is enabled by default, but there's a way to turn it off if you want. This is along the same lines of a debug assert macro. There is precedent with C's NDEBUG define for assert, but that doesn't mean that it's a good precedent to follow.

As for #9385, that's simply a mistake on my part of overlooking that debug output wasn't enabled by default for the compiler. I was curious why we didn't see a spike in compile-times when the previous pull request landed, but when #9385 lands we should see a spike. To go back to normal we'd just need to pass --disable-debug to the configure scripts on the bots.

Again though, sorry about forgetting to cc this here, I should have at least but "cc #8181" on one of the pulls :(.

[pnkfelix]

How about this for the #[cfg(not(ndebug))] problem: I can revise the configure and make files so that we always pass one of either --cfg debug or --cfg ndebug to rustc.

Then in our own code base, we can continue writing #[cfg(debug)] everywhere (apart from the implementation of the debug! macro obviously.

Does that sound okay?

(I know this only "solves" the problem for the rustc code base, apart from providing one pattern that others can choose whether or not they want to follow it, or invent other idioms. For now, my main goal is to try to enable our code base to be clean.)

[alexcrichton]

I'm totally OK with that. I suppose we could try it out and if it's super nice we may want to consider making it an actual language thing, but I don't think that'll happen soon...

[pnkfelix]

(i wouldn't want to make it a language thing anyway. :) I'll put up a PR soon.)

[huonw]

I could imagine that -g implying --cfg debug would be ok? (Only when it is decided that debug symbols work well enough to reinstate -g, of course.)

[pnkfelix]

@huonw I wouldn't object to -g implying --cfg debug.

(I'm less sure about the semi-analogous question of whether the absence of -g should imply --cfg ndebug; but that's not what you proposed so I'll just pretend I didn't mention it.)

[alexcrichton]

@pnkfelix, I went ahead and updated #9385 to add --cfg debug on some builds and --cfg ndebug in others.

[alexcrichton]

This is essentially done. Instead of --cfg debug we now have --cfg ndebug, meaning that by default debug logging is turned on.

Debug-info is another story, bug I think that today's incarnation of the compiler we have enough default logging as is.