-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[beta] 1.46 beta #74323
[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.