anchors: consider YAML oddities

[ccoVeille]

Right now the YAML syntax is ambiguous for anchors and aliases.

The fact an anchor or alias name can contain a : leads to oddities.

For example, this is valid

---
a: &foo: 42
m:
  - bar
  - *foo:

It will result to this

a: 42
m:
  - bar
  - 42

It's uncommon, but why not after all. The YAML specification supports it.

But now, consider this:

---
a: &foo 42
m:
  *foo: bar

What is it about ?

• an alias and anchor named foo ?

  So this

   a: 42
   m:
     42: bar

  But then the valid YAML syntax for would be this:

   ---
   a: &foo 42
   m:
     *foo : bar

  With a space after *foo before the :, here it's because of the possible trailing : in alias name

  Please note, that right now, yamllint:
  - does not report using *foo: is ambiguous while it should/could, even if it's via a setting like "forbid ambiguous anchor name".
  - would report there is an extra space after the *foo: while using *foo: bar is invalid in fact in YAML, as it means "the alias named foo: followed by the scalar bar".

• an anchor named foo and alias named foo: (with trailing :)

  Because then it would be this

   ---
   a: 42
   m:
     NULL bar

  which is invalid

This is unlikely to happen, so it proves it will occur 😄

I would prefer if yamllint could report that using an anchor with a trailing : as invalid, and report using an alias followed by a : in map is invalid.

cc @mikefarah @ingydotnet

I found this while taking a look at

• Anchor map key with no space before colon works in v3; breaks in v4 yaml/go-yaml#109

[adrienverge]

Hello @ccoVeille,

Thanks for these interesting thoughts!

I agree that the fact that it's a rare problem, doesn't mean we shouldn't address it.

Can you please tell which one of your 2 interpretations is the correct one, according to the YAML specification?
(For info, the parser PyYAML uses the 1st one, i.e. it outputs {a: 42, m: {42: bar}} -- but PyYAML is sometimes wrong.)

Depending on this, we could think about a solution (maybe a new option in yamllint rule anchors, or maybe tolerating spaces before : in some cases).

PS: I'm curious about what @mikefarah and @ingydotnet think. Also @perlpunk, maybe you have an opinion on this?

[ccoVeille]

@adrienverge I don't think there is something in the spec about the fact this would be invalid. It depends on how you understand the spec and the consequence of each statement.

That's why it's ambiguous.

Some parsers accepts it, some doesn't.

Most of the time when they support colon in anchor/alias name, they have no real solution without marking *key: value as invalid.

So to rephrase my suggestions here, I would say:

• an anchor/alias containing a colon should be reported as ambiguous by default, I think. Especially a trailing colon in an alias name.
• when an alias is used as a key in a mapping node, there must be an extra space before the : that identify the "this is the key, and this is the value". But, here I don't know if having the extra space should be suggested by default, as it would depend on the parser that will read the YAML data.

[ingydotnet]

I pretty much concur. Anchors containing : , while spec legal should be discouraged.

All aliases as keys should have a space between them and the colon to work with the most loaders.

Pyyaml, libyaml and go-yaml will probably never support : in anchor names.

[adrienverge]

Thanks for your feedback @ccoVeille @ingydotnet 👍

Thus I propose a new option forbid-ambiguous-anchor-names: true | false in rule anchors, that would check whether anchors contain a : character.

Given that : in anchor names was never supported by major YAML parsers, I think this new option could be enabled by default for everybody:

rules:
  anchors:
    forbid-undeclared-aliases: true
    forbid-duplicated-anchors: false
    forbid-unused-anchors: false
    forbid-ambiguous-anchor-names: true  # ← new option

Contributions are welcome!

[ccoVeille]

I'm glad we managed to convince you.

I have a question anyway.

While your position is clear on having no ambiguous anchor name, what is your position on having the need to emit a space after an alias in a mapping key?

Thanks

[perlpunk]

PS: I'm curious about what @mikefarah and @ingydotnet think. Also @perlpunk, maybe you have an opinion on this?

Just adding my 2 cents.
I think the new option makes sense.

And emitting a space after an alias key is something that is necessary according to the spec, and I implemented this in libyaml, so I think every library should do it. I don't see a disadvantage with this. Especially if we will have a linter now that warns about it.

[ingydotnet]

@perlpunk is spot on here.

[adrienverge]

Thanks for your input too @perlpunk 👍

While your position is clear on having no ambiguous anchor name, what is your position on having the need to emit a space after an alias in a mapping key?

From what I just read above, emitting a space after an alias key is mandatory, according to the spec. So in my opinion, YAML parsers should fail and report such missing space after an alias key.

But apparently some of them don't (e.g. PyYAML), so indeed yamllint could help. For example with a new option require-space-after-alias-key?

rules:
  anchors:
    forbid-undeclared-aliases: true
    forbid-duplicated-anchors: false
    forbid-unused-anchors: false
    forbid-ambiguous-anchor-names: true  # ← new option
    require-space-after-alias-key: true  # ← new option

(Feel free to criticize the new names, while they're not implemented!)