Generalize code for the two syntaxes defining expansions

[ClementSparrow]

Currently, there are two syntaxes to introduce new expansion contexts:

• identifier-defined: When we declare a new object and (in the future), when we declare a property or aggregate or synonym in the LEGEND section, the tag classes used in the object name define an expansion context.
• parameters-defined: In the COLLISIONLAYERS and RULES sections, when we list known properties and tag classes before a ->.

Common code should be written for all the occurrances of each syntax so that we can easily reuse the syntax to add expansion mechanisms elsewhere (including new features of the engine). The code should be able to manage some of the features needed for parsing the syntax that introduces the expansion context, and some of the features needed to use the expansion context (i.e., check if a specific expansion makes sense in that context, compute the expansion, and log errors).

[ClementSparrow]

TODO:

• identify the parts of the code that need to be generalized.
• move expansion code out of identifiers.js, to a new file.

[ClementSparrow]

Identifier-defined

• parser.js:
  • setSpriteMatrix uses current_expansion_context trivially.
  • tokenInObjectSection
    • case 1 sets current_expansion_context with expansion_context_from_identifier then filters it to remove objects that have already been explicitly declared -> expansion_context_from_identifier is only used there and should be the entry point for the creation of all identifier-defined expansion contexts. The filtering out of explicitly declared identifiers should be moved into this function, maybe opted out with a parameter of the function.
    • case 2 uses current_expansion_context to set colors in the objects' palette (section "Set colors in every object defined") -> this should be done outside parsing, like for sprite transforms, and palettes should be cached, i.e. only the list of the colors in the object declaration should be kept in the parser and passed to the compiler.
    • case 3 in test of copy: instruction: tests if the current_expansion_context has ambiguous (duplicated) parameters -> this should be done when the name of the object to copy from has been parsed, directly in expansion_context_from_identifier.
    • case 3 also calls setSpriteMatrix before switching to case 5.
    • case 3 also uses current_expansion_context to compute the color corresponding to one pixel and check it's not a number greater than the size of one expanded object's palette. -> For performance reason, this should be pre-computed once the palette line is parsed (we can assume the palette can be expanded too). For this computation, we may benefit from a generic function that computes the set of possible values returned by some function for all expanded identifiers? The resulting list of color sets could be used in case 2 to save memory concerning the data to pass to the compiler?
    • case 4 replaces current_expansion_context with an empty one if the name of the object to copy from is invalid. -> This seems like being not exactly what we want (quick fix?), as the parsing of the sprite transforms on the following lines will not be checked properly. Instead, in case 5, we should only push compiled_transformation in the last sprites_to_compile if that sprite_to_compile was defined in case 4.
    • case 4 uses current_expansion_context to expand the names of objects to copy sprites from (and check they are valid) with replace_parameters. -> see comment in code there, a new function is required that would also be used in case 5.
    • case 5 uses current_expansion_context to pre-compute the (potentially mapped) expansion of each tag in a sprite transform according to the expansion context and expected tag type (dir or int), and check that each expansion is unambiguous (no duplicated parameter in the context) -> see previous point.

Parameters-defined

• parser.js:
  • addIdentifierInCollisionLayer uses replace_parameters with the expansion context provided
  • tokenInCollisionLayersSection: collects parameter names then generates an expansion context after the ->. Apply addIdentifierToCollisionLayer to each item in current_expansion_context.
• compiler/rule_expansion.js:
  • generateRuleExpansion uses make_expansion_parameter
  • applyRuleParametersMappings uses replace_parameters and replace_directional_tag_mappings.