r? @cuviper

rustbot has assigned @cuviper.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

I think in #125046 I should have only denied #[linkage] static mut for extern statics. Basically moving the code I added in compiler/rustc_codegen_ssa/src/codegen_attrs.rs into the if tcx.is_foreign_item(did) arm.

I think in #125046 I should have only denied #[linkage] static mut for extern statics. Basically moving the code I added in compiler/rustc_codegen_ssa/src/codegen_attrs.rs into the if tcx.is_foreign_item(did) arm.

Right, but even then I don't see why Task::p wouldn't need to implement Send as it's still passed from one thread (added to the list in Thread::new) to another (removed from the list in Thread::entry).

Anyway, I believe this PR still cleans up the code.

Yeah, seems preferable this way.
@bors r+

📌 Commit 70f8310 has been approved by workingjubilee

It is now in the queue for this repository.

@bors r-

Waiting for @jethrogb's approval.

hm in fact
@bors delegate=jethrogb

✌️ @jethrogb, you can now approve this pull request!

If @workingjubilee told you to "r=me" after making some further change, please make that change, then do @bors r=@workingjubilee

@bors r+

📌 Commit 8db363c has been approved by jethrogb

It is now in the queue for this repository.

bors sleepy @bors r-

@fmease I'm confused about what you're trying to do. This PR is merged into master.

Just maintenance. Sometimes @bors's queue gets out of sync with GitHub (e.g., containing already merged PRs). While I could press the "synchronize" button, it's a bit destructive and buggy (try-builds get upgraded to builds, failing PRs suddenly show up in the queue, etc.). Therefore it's typical for someone to swoop in and manually "sync" the queue by r-'ing already merged PRs which still show up in the queue.