* replaced `.expect()` that provided no useful information with `.unwrap()`
* used `use` consistently (all types are `use`d all functions have the parent module `use`d)
* other formatting consistencies
* vulkano_shaders_derive exposes a proc_macro instead of a proc_macro_derive
* move vulkano_shader out of vulkano_shaders_derive and deprecate vulkano_shaders_derive
* Update documentation
* Move vulkano_shader! to root of mod, so it works with rust 1.30
SPIR-V allows the array stride and size of a type to differ, but rust defines them to be the same. Thus
certain types when represented in rust will have the wrong layout. E.g. an array of vec3 can have an array
stride of 16 in SPIR-V, but an array of [f32;3] in rust would have a stride of 12. Thus using one for the
other would cause corruption.
This suggests a workaround by using a wrapping struct or upgrading the size of the type to one where the size
is the array stride.
I considered generating the wrapping struct for the user, but that seems very confusing for the user. We could
generate wrapping structs for all vec and mat types in arrays, but that would be a large API change.
See #298.
* Use 'greater than' instead of 'superior to'.
Using 'X is superior to Y' to mean 'X > Y' is not standard mathematical usage. I
think I've seen 'superior to' used in lattice theory, but that's not relevant to
these cases.
* trait RenderPassDesc: Correctly describe when `None` is returned.
This seems to be an off-by-one error in the documentation. Looking at the
implementations generated in `src/framebuffer/macros.rs`, for example,
the various elements of each sequence are numbered from 0 to n-1.
* Typo: 'anistropic' -> 'anisotropic'.
* sampler::MipmapMode::Linear: Clarify description.
The docs seem to suggest that if the dimensions match a given level D, then
`Linear` would use levels D-1 and D+1, which is senseless. The new wording is
meant to be closer to the calculation described in Vulkan 1.1.82 §15.6.7.
* Typo: 'transitionned' -> 'transitioned', and similar.
* Doc fix: 'more optimal' -> 'more efficient'
Rationale for the curious:
'Optimal' is an absolute; once something is optimal, it cannot be made more so.
Absolutes can be weakened, as in 'almost optimal', but not strengthened, as in
'more optimal' or 'very optimal'. 'Efficient' is not an absolute: one thing
might be 'more efficient' than another.
* Minor doc fixes.
* Doc fix: 'performances' -> 'performance' throughout.
* Add new template parameters for GraphicsPipelineBuilder
* Add support for the specialization constants in build()
* Fix SpecializationConstants fields being private
* Fix lifetime problem in SpecializationConstants::descriptors()
* Run rustfmt on builder.rs
