Issue #30592: Restore build in --disable-jemalloc mode. #30662
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @aturon (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
Could this patch be responsible for breaking |
|
Thanks @petevine for spotting this; I'm not 100% sure it's related however I'm testing a patch to verify and fix if it's indeed related. |
|
Yeah, probably a complete shot in the dark but seeing the additional EDIT: |
|
Looks good. Can you please add comments to both of the cfg's explaining why they are doing what they are doing? Otherwise they will become mysteries (I can't even see why the second commit is needed so a comment will def help). |
|
Comments have been added as requested. I hope they're correct, as I'm not allocator specialist (I came up with this patch by finding the minimal working revert of cd1848a, that caused the issue in the first place). |
|
|
||
| // Don't inject an allocator in stage0 since we explicitly use alloc_system, jemalloc | ||
| // being possibly unavailable or disallowed | ||
| #![cfg_attr(not(stage0), needs_allocator)] |
There was a problem hiding this comment.
I think the build should be able to complete even if this attribute is present (e.g. this crate always needs an allocator). Did you run into an error if it was present in stage0?
There was a problem hiding this comment.
That's the part where I'm not crystal clear what's happening; I had to reinstate this line to avoid the issue described in the issue, with make install starting from stage0 after a successful build
There was a problem hiding this comment.
Ah in that case the make install issue was likely unrelated and connected to some other series of events. I believe that if this is reverted back to as-it-was it should bootstrap A-OK
There was a problem hiding this comment.
I tend to agree as I fail to reproduce now, but I've upgraded rustc in the meanwhile. @joerg-krause
I see you used the second commit in your tree, therefore I believe you encountered the "make install triggers stage 0" issue as well. If that's correct, does "make -d" give the reason why make starts back at stage 0? Thanks.
There was a problem hiding this comment.
Honestly, I picked the second issue because it was comitted together with the first one. Furthermore, I am not sure when make install should not start at stage0. If I do a change in Rust, make install will always start at stage0, right?
|
Ok, thanks. Let me remove the last commit, and let's confirm everything is still OK. |
|
I built an |
Fixes #30592, a fallout of cd1848a