Cylc-flow: Unhelpful error message for backslash section end

[sadielbartholomew]

Minimal illustrative example

cylc validate reports Illegal item: [scheduling][special tasks]R1 (& fails) for the following, where really we should point to the use of a section ending with a line continuation character.

[scheduling]
    initial cycle point = 2000
    [[special tasks]]
        clock-trigger = \
                        one(PT1M), \
                        two(PT1M), \
    [[dependencies]]
        [[[R1]]]
            graph = """
                one => two
            """

For context as to why someone would end up doing this, a user was specifying various lines, contributing together towards a setting value, ending , \ via Jinja2 conditionals, therefore the specific configuration dictated which of those lines was the final one, all having the comma to combine validly.

Note: validation passes when there is a blank line after the line with two(PT1M), \ i.e. directly before the next section heading. So the above isn't a bug per se, as use of a backslash implies follow-on on the next line, which is resolved e.g. by the blank line with its \n.

[hjoliver]

I think the error here is actually over-simplistic parsing of clock-trigger = .... The extra line continuation marker (user error) results in this:

clock-trigger = one(PT1M), two(PT1M), [[dependencies]]

If validation flagged that line as an error, that would be fine IMO. Legal values of clock-trigger should not contain square brackets.

[sadielbartholomew]

I understand that, as I tried but probably failed to convey:

So the above isn't a bug per se, as use of a backslash implies follow-on on the next line, which is resolved e.g. by the blank line with its n.

In the minimal working example I provided, the issue is obviously very clear, however imagine as in the discovery case, as we debugged for a user, that this is all hidden behind Jinja2 statements. So we were presented with something like:

...
        clock-trigger = \
{% for MODEL in list_models %}
{% if MODEL == RUN_ENLIL %}
                        swe_start(PT3H), swe_res_create(-PT1H), \
{% endif %}
{% if MODEL == RUN_ENLIL_ENS %}
                        swx_start(PT3H), swx_res_create(-PT1H), \
{% endif %}

...

{% if MODEL == RUN_UGONG %}
                        swu_start(PT3H), swu_res_create(-PT1H), \
{% endif %}
{% endfor %}
    [[dependencies]]
...

However, I am happy to close this given uou think it is not strictly an 'issue'. The behaviour has at least been registered now, should it perplex any of us or any users again.

[hjoliver]

For the record, my analysis above was wrong - square-bracketed items are correctly flagged as errors in clock-trigger list values. The problem is that the erroneous section heading after the clock-trigger list (which results from the correct heading being absorbed into the clock-trigger list) is seen first by the parser, before the clock-trigger list values are parsed. In light of this, the original error message is correct, although the one that would result if clock-triggers were parsed first would be easier to understand.

Finally, I'll note that it would be very difficult for us to detect that a section ends with a continuation marker, because we do line concatenation first, before any lines are parsed. i.e. continuation markers are gone by the time we can know where a section ends.

So, @sadielbartholomew - I think you were right to flag this as something that should be done better. I'm not sure what the best fix is at this point though (and it's not super urgent, compared to other things...)

[hjoliver]

(Line continuation markers are always dangerous of course - i.e. user beware. As well as the problem here, they also get silently "switched off" by invisible trailing whitespace)