Update troubles list

TROUBLES.md

@@ -1,24 +1,29 @@
 # Troubles encountered with Rust during the making of this library
 
-- Lack of plugins means that you have to use a build script to compile your shaders instead of inlining them directly where they are used.
+- No way to store an object and its borrowing in the same struct. This is the reason why the whole API uses `Arc`s.
 
-- [No way to create dynamic-sized arrays on the stack](https://github.com/rust-lang/rfcs/issues/618). A lot of Vulkan functions require
+- Lack of plugins means that you have to use a build script to compile your shaders instead of inlining them directly where they are used.
-  passing an array of small elements (small structs or integers). Building such an array with a `Vec` can be expensive, especially
+  In addition to this, lots of existing macros would be much simpler to implement with plugins. The code generated by macros is currently
-  when most of the time the array only contains a single element.
+  inefficient because using the efficient way would make the code very difficult to read.
 
 - Having a trait that defines which types can be put inside buffers is very annoying, as users have to implement it for every single struct
   they create. The best solution would be to use `impl BufferContent for ... {}`, but this syntax is still unstable.
 
-- No way to create a `*mut T` pointer from a `*mut c_void` and a size when `T` is unsized. This had to be implemented in a custom
+- When `T` is unsized, there's no way to create a `*mut T` pointer from a `*mut c_void` and a size. This had to be implemented in a custom
   trait.
 
-- [Can't cast an `ImageResource` into a `Resource` even though the former depends on the latter](https://github.com/rust-lang/rust/issues/5665).
+- The fact that is legal to implement `Deref` and make `deref()` return a different object every time means that it is dangerous to interface
+  with a `Foo` through a `P where P: Deref<Foo>`. That `P` could return several different `Foo`s every time you deref it, and the implementation
+  can't rely on the fact that the object will be the same every time.
 
 - This library was designed with specialization in mind. There are several `is_compatible` trait methods that perform deep comparisons between
   layouts. With specialization available, these methods could be specialized as `true` for layouts that are known to always be compatible.
 
 - https://github.com/rust-lang/rust/issues/29328
 
+- "Source trait is private" errors when traits are declared in private modules but reexported publicly from a parent module. Not sure if that's
+  a bug or a feature from the privacy system.
+
 - Some trait implementations have an associated type that looks like `type T = (Arc<Foo>, Arc<Bar>);`. HKTs would allow this parameter to take
   references to the Arcs instead, and avoid having to clone them. This problem could by bypassed by making the code more ugly, but it's not worth
   it just to avoid cloning some Arcs.
@@ -28,10 +33,12 @@
 
 - This repository contains the `vulkano-shaders` library, which generates Rust code that uses the `vulkano` library. If the API of `vulkano` gets
   a breaking change, there is no way to enforce or to check the fact that the user uses a correct combination of versions for `vulkano-shaders`
-  and `vulkano`.
+  and `vulkano`. Procedural macros declared in `vulkano` itself would solve this (https://github.com/rust-lang/rfcs/pull/1566).
 
-- No way to set the alignment of a struct member, or to force the size of a struct to be a multiple of a certain size.
+- No way to set the alignment of a struct member, or to force the size of a struct to be a multiple of a certain size. Some parts of the Vulkan
+  API enforce some limitations regarding the alignment, and the user currently has to manually add dummy padding fields.
 
-- The fact that is legal to implement `Deref` and return a different object every time means that it is dangerous to interface with a `Foo`
+- [No way to create dynamic-sized arrays on the stack](https://github.com/rust-lang/rfcs/issues/618). A lot of Vulkan functions require
-  through a `P where P: Deref<Foo>`. That `P` could return several different `Foo`s, and the implementation can't rely on the fact that the
+  passing an array of small elements (small structs or integers). Building such an array with a `Vec` can be expensive, especially
-  object will be the same every time.
+  when most of the time the array only contains a single element. This is currently solved with the `SmallVec` type, but doing so wastes
+  memory.