-
Notifications
You must be signed in to change notification settings - Fork 13.3k
[beta] 1.46 beta #74323
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
[beta] 1.46 beta #74323
Conversation
@bors r+ rollup=never p=20 |
📌 Commit 2af7940 has been approved by |
⌛ Testing commit 2af7940 with merge 07b17aaa944283e075e8e965d6954d26076c5823... |
@bors treeclosed=5 will continue to manually shepherd today |
💔 Test failed - checks-actions |
|
I think we're going to have to wait for the rust ap stuff |
Once the ap stuff goes through would you mind updating this PR to include the clippy update? (currently in CI) |
Oh right, I forgot we never fixed toolstate this cycle. Indeed this will need to wait for that and we'll just re-promote at that point (basically rebasing atop master) I imagine. |
⌛ Testing commit 2af7940 with merge 8309d7fda7313002b8b50cbbcbd3efe0827bf789... |
@bors r- This had failed, no? |
homu seems to have gotten confused |
@bors yield |
#72920 landed in the same rollup as the fix for the toolstate failures on rustfmt/RLS so we didn't note that the fix didn't actually fix things (since that PR introduced a regression, technically, in beta-week). I don't know that tooling could've detected it though -- I guess we should just not rollup toolstate-fixing PRs in beta week? Anyway, I pushed up a dummy commit that just re-adds that const_transmute feature on a dummy function and seems to fix the build for RLS and rustfmt locally -- hopefully that's also the case on CI. @bors r+ rollup=never p=20 |
📌 Commit 83b6d84 has been approved by |
💡 This pull request was already approved, no need to approve it again.
|
📌 Commit 83b6d84 has been approved by |
⌛ Testing commit 83b6d84 with merge c20a0a4ad0888cb28993511e6f1e87ce622bd87c... |
|
@bors r+ rollup=never p=20 Tools builder is passing on the PR at least. |
📌 Commit dba515e has been approved by |
Miri should not be built on beta and stable. |
Miri failures are ignored -- we do currently try to build it, though. I'd be happy to take a patch that doesn't do so. |
That's what #73232 was supposed to fix 🤔 |
You're not wrong, but indeed the tools builder explicitly lists miri (
x.py build for example will they affect things.
My guess is we can add some logic around ( Line 358 in c724b67
|
⌛ Testing commit dba515e with merge 139f54761d07ff14bbb3794bb687fa6de4227a19... |
I'll cc @RalfJung in case they want to continue work on #74323 (comment) |
I am not very familiar with that glue code. Wouldn't it make more sense to adjust
to not build nightly-only tools on non-nightly branches? |
That would work too, I'm just less familiar with bash so would need to probably put in more effort (and we'd have a duplicate list of stable/unstable tools). |
OTOH it seems odd that an explicit request to build & test Miri would be ignored, even if the channel is stable. Ideally the Python script that has the stable/unstable list would also drive |
@bors retry - this failed forever ago https://github.com/rust-lang-ci/rust/runs/874170463 |
☀️ Test successful - checks-actions, checks-azure |
How did this land now if Miri is failing? |
Miri fail is non fatal. It doesn't stop the build. |
Oh so the problem that came up here is that the build happened at all, not that the failure was a problem? |
I haven't checked the logs but something else must have failed. |
Okay I thought there was an actual problem here not just "we are running more tests than we should". Oh well. Here's my partial attempt at fixing this: #74389. But I give up here, rustbuild is too hard to work on I am afraid and my Miri TODO list is already overflowing with other stuff. ;) Hopefully this is a start that someone else can build on, if anyone cares. |
No description provided.