Stream: t-compiler/major changes

Topic: Use sane defaults in x.py compiler-team#326


triagebot (Jul 02 2020 at 14:25, on Zulip):

A new proposal has been announced: #326. It will be
announced at the next meeting to try and draw attention to it,
but usually MCPs are not discussed during triage meetings. If
you think this would benefit from discussion amongst the
team, consider proposing a design meeting.

Jonas Schievink (Jul 02 2020 at 14:28, on Zulip):

Don't build stage1 rustc artifacts with x.py build --stage 1. If this is what you want, use x.py build --stage 2 instead, which gives you a working libstd.

What does this mean exactly? That the compiler built with --stage 1 (or without, since the proposal makes it the default) won't be able to compile code that requires the standard library?

Jonas Schievink (Jul 02 2020 at 14:29, on Zulip):

Ah nevermind, I see

Joshua Nelson (Jul 02 2020 at 14:40, on Zulip):

That the compiler built with --stage 1 (or without, since the proposal makes it the default) won't be able to compile code that requires the standard library?

That is the current behavior: the stage2 compiler (stage1 artifact) will not have a working libcore. My proposal is to always build libstd+libcore at the same time as the compiler, since the current situation of compiler without libcore is not very useful.

mark-i-m (Jul 02 2020 at 15:20, on Zulip):

My major concern here is that we would be defaulting to technically unsound builds, right? e.g. a stage 1 compiler might not always work correctly

simulacrum (Jul 02 2020 at 15:42, on Zulip):

no, it should always work correctly

simulacrum (Jul 02 2020 at 15:43, on Zulip):

it's just that you're not perfectly matching what users see -- in particular, if you break the compiler (codegen, mostly) in such a way that std isn't affected but the compiler itself is you could miss that

simulacrum (Jul 02 2020 at 15:43, on Zulip):

but since CI will still be checking stage2, this isn't all that big a concern imo

simulacrum (Jul 02 2020 at 15:43, on Zulip):

it used to be that stage2 was needed for proc macros because they linked against the compiler itself, but that's also no longer true

mark-i-m (Jul 02 2020 at 20:49, on Zulip):

That's good to know, but I feel like I've seen tests fail at stage 1 and not on stage 2 before (though it's been a while since that happened last)

simulacrum (Jul 02 2020 at 20:52, on Zulip):

that should only be if the test does e.g. extern crate rustc_metadata; or similar. Everything else is almost certainly a bug these days

mark-i-m (Jul 02 2020 at 20:55, on Zulip):

Ok, I will be on the watch for that next time I build locally

nikomatsakis (Jul 02 2020 at 21:05, on Zulip):

I feel pretty good about these defaults.

Joshua Nelson (Jul 02 2020 at 21:17, on Zulip):

There was some feedback in https://github.com/rust-lang/rust/pull/73964#issuecomment-653134345 that debug = true makes the fast path for "run all the tests" slightly slower. Personally I would find it hard to debug things without RUST_LOG=debug but since this is only a default I'm fine changing it keeping it as is.

Josh Triplett (Jul 03 2020 at 02:06, on Zulip):

Is there some way we could compile in enough support for RUST_LOG=debug without actually having debug symbols?

Josh Triplett (Jul 03 2020 at 02:07, on Zulip):

Otherwise this seems great to me. I would just like to further reduce build time and link time, if we can.

Joshua Nelson (Jul 03 2020 at 04:50, on Zulip):

@Josh Triplett we could set debug = true and debuginfo = 0. That would still have debug assertions but I think that's a good thing, if you're breaking invariants during tests you should know about it.

It would be great to have some statistics on how much time debuginfo = 1 adds to the build, if it's 10 seconds out of a 5 minute build I doubt there would be much opposition.

Joshua Nelson (Jul 03 2020 at 04:51, on Zulip):

Also see my comment on the PR - debuginfo 1 takes a lot less time than debuginfo 2

Josh Triplett (Jul 03 2020 at 06:53, on Zulip):

I'm actually less concerned about the time (given comments that it's apparently negligible) and more concerned about memory usage during the build.

Josh Triplett (Jul 03 2020 at 06:54, on Zulip):

I'm hoping debug 1 will be an improvement in that regard.

simulacrum (Jul 03 2020 at 12:11, on Zulip):

debug asserts are a pretty big performance hit last I checked, which is why we have a separate debug-assertions-std now (but just compiler asserts are still a 50% hit in performance IIRC)

Joshua Nelson (Jul 03 2020 at 12:59, on Zulip):

Ok, it sounds like debug = true is not the best change for everyone (or at least, not a clear win the way the other changes are). I'll remove it from the MCP and my PR.

Joshua Nelson (Jul 07 2020 at 21:12, on Zulip):

This has gone a few days without discussion or a second ... Did I miss a concern someone had? If not, what are the next steps?

Josh Triplett (Jul 07 2020 at 21:37, on Zulip):

I think the next step would be to convert the draft PR to a non-draft PR, and suggest that someone on the team do an "rfcbot merge" to confirm consensus.

Joshua Nelson (Jul 07 2020 at 21:39, on Zulip):

Neat, that means I need to fix the test failures first then :laughing: thanks!

Josh Triplett (Jul 07 2020 at 21:40, on Zulip):

Also, a request: could you please change the PR/commit title, to something like "Improve defaults in x.py", rather than using "sane"? I don't think it's appropriate to use terms like "sane" in this context, both because they're pejorative to the past code (implying it's "insane" rather than just suboptimal), and because analogies to mental illness are problematic for various reasons. (This is something I'm still working on myself, but I try to catch it and deal with it when I notice it.)

Joshua Nelson (Jul 07 2020 at 21:43, on Zulip):

(this stream resumes at https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Improve.20defaults.20in.20x.2Epy.20compiler-team.23326)

Last update: May 07 2021 at 06:15UTC