Remove unsound SendSyncWrapper

[daxpedda]

I noticed that SendSyncWrapper caused some real issues here and there. First #3270 and #3288, then #3297.

Also noticed that we simply used SendSyncWrapper on Fullscreen inside WindowBuilder, but there is a getter that exposes this information to the user, bypassing the !Sync on Fullscreen on MacOS, depending if this !Sync was correct or not, that may have been unsound.

Additionally on Web there was an issue where dropping WindowBuilder outside the main thread could cause it to try and drop HtmlCanvasElement, which is unsound as well (not entirely sure if that is correct, but it's at least semantically correct).

Additionally implementing Debug on SendSyncWrapper was unsound as well, because Debug could access the inner value off the only thread it was intended to be accessed on. Which was the case for WindowBuilder on Web with HtmlCanvasElement and the custom wrapper I used for CustomCursor.

All in all I would say SendSyncWrapper is a footgun and apart from the RawWindowHandle v0.4 and v0.5 we didn't even really need it.

[kchibisov]

Additionally implementing Debug on SendSyncWrapper was unsound as well, because Debug could access the inner value off the only thread it was intended to be accessed on. Which was the case for WindowBuilder on Web with HtmlCanvasElement and the custom wrapper I used for CustomCursor.

reading pointer value is not unsound by any means, if you deref raw pointers during Debug it's already concerning.

Also noticed that we simply used SendSyncWrapper on Fullscreen inside WindowBuilder, but there is a getter that exposes this information to the user, bypassing the !Sync on Fullscreen on MacOS, depending if this !Sync was correct or not, that may have been unsound.

you can't do anything with it outside the main thread, and if you can do then builder has nothing to do with it, we have the same API throughout the code base on a Send + Sync types with the exact same values.

[daxpedda]

reading pointer value is not unsound by any means, if you deref raw pointers during Debug it's already concerning.

I think you are talking about RawWindowHandle. HtmlCanvasElement is not a pointer and neither is Fullscreen.
But that is the footgun I was talking about, we were using SendSyncWrapper on types that aren't a pointer.

you can't do anything with it outside the main thread, and if you can do then builder has nothing to do with it, we have the same API throughout the code base on a Send + Sync types with the exact same values.

I think there is a misunderstanding here.
WindowBuilder is Send + Sync, the public API allows you to extract the Fullscreen type from the WindowBuilder and access it. Now the user can do this over multiple threads at the same time, because WindowBuilder is Send + Sync, and Fullscreen grants access to a VideoMode, which has a bunch of methods that users could call on a type in parallel that isn't Sync.

If this isn't an issue, then VideoMode should be Sync, making Fullscreen Sync automatically.

[kchibisov]

I think there is a misunderstanding here.
WindowBuilder is Send + Sync, the public API allows you to extract the Fullscreen type from the WindowBuilder and access it. Now the user can do this over multiple threads at the same time, because WindowBuilder is Send + Sync, and Fullscreen grants access to a VideoMode, which has a bunch of methods that users could call on a type in parallel that isn't Sync.

If this isn't an issue, then VideoMode should be Sync, making Fullscreen Sync automatically.

Window is Send + Sync as well and uses the same API, if macOS is bugged macOS should be fixed, nothing.

[daxpedda]

Window is Send + Sync as well and uses the same API, if macOS is bugged macOS should be fixed, nothing.

This isn't the same thing, Window doesn't return references to Fullscreen, but owned values, the resulting Fullscreen is then !Sync, so no violations there.

I hope the problem is apparent now, SendSynWrapper is just a footgun because it's not simple to reason about these things, especially when we have so many very different backends.

[madsmtm]

Flyby review, unsure what's the correct approach here.

[madsmtm]

See also #3142 for improvements here.

[daxpedda]

I split out the Web part into #3320.
So now all that needs to be done here is figure out Sync for VideoMode for MacOS.