allow ZST entry params in input and output positions

[Firestar99]

With ZST entry params, you can do some cursed generic entry point stuff to make certain inputs and outputs optional:

rust-gpu/tests/compiletests/ui/spirv-attr/entry_generic.rs

Lines 19 to 28 in 5f1d97f

	#[spirv(vertex)]
	pub fn main<T: Copy>(in1: T, out1: &mut T) {
	*out1 = in1;
	}
	pub fn dummy() {
	main::<u32>(0, &mut 0);
	main::<f32>(0., &mut 0.);
	main::<()>((), &mut ());
	}

[Ralith]

As a prospective user, I think having entry points appear as a side-effect of monomorphization is potentially very difficult to reason about. I'd rather just write out the entry points I want.

[LegNeato]

Oh this is fun

[Firestar99]

I think having entry points appear as a side-effect of monomorphization is potentially very difficult to reason about. I'd rather just write out the entry points I want.

I can get behind that monomorpization generating entry points is very cheesy, but I wouldn't outright ban people from making generic entry points. Afterall, it's an active choice you make as a developer to declare your entry point generic, and you can always resort to macros to generate all the variants you want.

Using generics on entry points has always been possible, even if I don't know anyone using it atm. This PR only allows entry point params that are ZST to be ignored instead of erroring, which would even help both with generic and macro case by you not having to explicitly remove args but being able to just ZST them away.

A bigger issue with monomorpization is that rustc doesn't monomorphize functions that are not "exported" aka visible from an outside crate. So the entry point must be pub, all modules leading to it must be pub, or you need to pub reexport it somehow. Which is also why fn dummy() must be pub in the example. See #293 and #155

[Ralith]

Using generics on entry points has always been possible

Fair, I guess the discussion is out of scope for this PR then.