destroy_block() is called with a NULL block from:
* create_loop, through the loop rules for while and do-while loops.
* The selection_statement rule, in the case $6.else_block is NULL.
* free_parse_initializer.
After compiling and linking with '-fsanitize=undefined' the following
error pops up in many tests:
vkd3d_shader_main.c:2024:12: runtime error: member access within null pointer of type 'struct vkd3d_shader_param_node'
This happens in the scenario where shader_param_allocator_get() gets
called with 'count = 0' but no allocation has been made yet, so
allocator->current is NULL.
In this case the result of the function, given by:
params = &allocator->current->param[allocator->index * allocator->stride];
is an invalid non-NULL pointer.
Functions like shader_sm4_read_instruction() may call
vsir_program_get_src_params() or vsir_program_get_dst_params() with 0
counts for various DCL_ instructions, as well as things like NOP,
ELSE, and SYNC.
We could avoid calling the functions in question with 0 counts, but it
doesn't seem worth the effort.
Alternatively, we could just return NULL on 'count == 0', but this is
also complicated because NULL is interpreted as a memory allocation
failure on the callers.
So we force allocation of the next node even if 'count = 0' when
allocator->current is NULL.
track_object_components_usage() had to be improved to also
register derefs on resource stores.
It was not doing it because it assumed that for every resource store
there was a resource load already, which was true, before calling DCE.
