Using the sm-winit feature on UWP

[asajeffrey]

If a user builds with the sm-winit feature on UWP, there's a compile error caused by

surfman/surfman/src/platform/windows/angle/surface.rs

Lines 116 to 118 in fb78226

	/// A placeholder native widget type for UWP, which isn't supported at the moment.
	#[cfg(target_vendor = "uwp")]
	pub struct NativeWidget;

and

surfman/surfman/src/platform/windows/angle/connection.rs

Lines 117 to 127 in fb78226

	#[cfg(feature = "sm-winit")]
	#[inline]
	pub fn create_native_widget_from_winit_window(&self, window: &Window)
	-> Result<NativeWidget, Error> {
	let hwnd = window.get_hwnd() as HWND;
	if hwnd.is_null() {
	Err(Error::IncompatibleNativeWidget)
	} else {
	Ok(NativeWidget { window_handle: hwnd })
	}
	}

. For extra fun, rust-lang/cargo#4463.

[jdm]

Why are we using sm-winit on UWP?

[asajeffrey]

Because cargo loves to take the union of features.

[asajeffrey]

Trying to debug why cargo builds a dep with a feature is painful. Cargo really believes that adding a feature adds functionality.

[jdm]

@asajeffrey I'm familiar with the cargo union, but confused about why we have uses of surfman that are requesting the sm-winit feature that are outside of ports/glutin.

[asajeffrey]

Me too. Did rust-lang/cargo#7756 change how features are resolved in workspaces, so the union of features is always taken?