[Fuzz] Raise error when entity aspect is missing in configuration specification.

[NikLeberg]

Based on crashing fuzzer input 0c1d01dd6f3aea51f8b086c4c788132486f2bfe6079eb33e89f4e69d39945bc7 from issue #1091.

Previously nvc allowed entity aspect to be non existent even though for such explicit cases I think even the standard requires it to be existent.

LRM 19 section 7.3.2.1: When a binding indication is used in an explicit configuration specification, it is an error if the entity aspect is absent.

[nickg]

I would check if bind != NULL in p_configuration_specification instead. The code would be simpler and the user gets a better error message:

tree_t bind = p_binding_indication(comp);
if (bind == NULL)
   parse_error(CURRENT_LOC, "a binding indication in an explicit configuration "
               "specification must contain an entity aspect");

[NikLeberg]

The else branch in p_binding_indication prevents that bind will ever be NULL for the case that we care about.

nvc/src/parse.c

Lines 9021 to 9022 in 4062b25

	else
	bind = tree_new(T_BINDING);

Otherwise that would be a nice and easy fix.

Up to now p_binding_indication returns three kinds of values:

• for ent0 : ent; => shallow tree obj i.e. a simple tree_new(T_BINDING), nothing else
• for ent0 : ent use entX; => a valid tree obj i.e. with location, reference, identifier etc.
• for ent0 : ent use open; => simply NULL

I tried to work around this with the new commit. First I removed the mentioned else branch as it seemed to have no purpose. (All tests pass regardless.) This gives us NULL for the first and also the last input case. We then differentiate one from the other by checking if we have a tOPEN.

I'm not sure if that is acceptable. I sadly don't know the downstream changes that the removal of the else branch introduces.

[NikLeberg]

Nevermind. The removal of the else branch most probably broke something called incremential binding. I'll come up with a MWE for that to see if it worked beforehand. If you happen to have a MWE pleaee share.