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.
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?
Ah nevermind, I see
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.
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
no, it should always work correctly
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
but since CI will still be checking stage2, this isn't all that big a concern imo
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
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)
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
Ok, I will be on the watch for that next time I build locally
I feel pretty good about these defaults.
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.
Is there some way we could compile in enough support for
RUST_LOG=debug without actually having debug symbols?
Otherwise this seems great to me. I would just like to further reduce build time and link time, if we can.
@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.
Also see my comment on the PR - debuginfo 1 takes a lot less time than debuginfo 2
I'm actually less concerned about the time (given comments that it's apparently negligible) and more concerned about memory usage during the build.
I'm hoping debug 1 will be an improvement in that regard.
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)
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.
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?
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.
Neat, that means I need to fix the test failures first then :laughing: thanks!
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.)