Make Clipboard::new unsafe

[SuchAFuriousDeath]

The smithay-clipboard Clipboard::new method requires the display pointer to remain valid for the lifetime of the Clipboard. Since egui-winit's Clipboard::new cannot guarantee this invariant, it must be marked unsafe and pass the safety requirement to the caller.

Fixes #7743 (more details there)

• Closes Safety hazard in Clipboard::new #7743
• I have followed the instructions in the PR template

[github-actions]

Preview available at https://egui-pr-preview.github.io/pr/7826-fix-clipboard-new-safety
Note that it might take a couple seconds for the update to show up after the preview_build workflow has completed.

View snapshot changes at kitdiff

[oscargus]

Would it make sense to have two variants of new depending on the config? One which is unsafe and one which is not?

Not sure how much of this is propagated up though or if it is just simpler to mark even the arboard variant unsafe? There is a risk that one will now have to deal with unsafe even if only the arboard version is used.

[SuchAFuriousDeath]

I'm not sure that's such a good idea. Maybe we could keep new safe and only enable it when smithay clipboard is disabled and then have an unsafe from_raw_handle method or something like that.

[SuchAFuriousDeath]

But it's breaking change either way.

[emilk]

Thanks!

[SuchAFuriousDeath]

Forgot to mention: This also probably closes #7660.

[SuchAFuriousDeath]

@emilk Actually there is a bit of a problem here. I think that if we really want to be 100% sound, then State::new should probably be unsafe as well, because again, the current function signature can't enforce that the safety requirements are actually upheld.
Per my analysis, the callers of State::new (inside egui) can actually uphold the safety requirements, so the unsafety would not bubble up further than that. But State::new is pub, so this would be one more breaking change.